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METHOD AND APPARATUS FOR NETWORK CENTRIC 
PROBLEM ANALYSIS AND TOPOLOGY CONSTRUCTION 



Cross-reference to Related A pplication 

This application is a continuation-in-part application of Serial No. 
08/493,984^ filed June 23, 1995, by James G. McGuire, Richard N. Pelavin, 
Herbert S, Madan, and entitled, System and Method for Evaluating Computer 
Network Performance. 

BACKGROUND OF THE TNVFNTION 

1. Field of the Invention 

The invention relates in general to computer networks, and more 
particularly, to the design, modification and management of computer 
networks. 

2. Description of the Related Art 

Computer networks comprise multiple computers that are 
interconnected for communication with each other. A network may include 
only a few computers physically located close together or it may include many 
computers dispersed over a wide area. A network may include subnetworks or 
local area networks (LANs), A network also may include widely separated 
computers interconnected over a wide area network (WAN). Routing devices, 
in essence, are specialized computer networking devices that route or guide 
packets of digitized information throughout a network. Typically, when a host 
computer sends a packet out onto a network, it includes in the packet address 
information that specifies the source of the packet, the sending host, and the 
intended destination of the packet, another host computer connected to the 
network. The sending aind receiving hosts ordinarily are interconnected 
through routing devices which usie packet address information to route packets 
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histoiy of changes to routing device configurations. There are network 
management stations that can collect information from network probes and 
present a network manager with data representing the state of the network. 
Simulation tools can predict the performance and behavior of hypothetical 

5 networks^ Topology rendering tools can be used to display a topology setting 
the context to identify possible problems on particular network components as 
well as network-wide problems. 

There are particularly difficult technical challenges in the realm of 
network management tools that identify possible network-wide problems and 

10 that render network topologies. For example, it can difficult to determine the 
logical connections between network devices without requiring a live 
operational network. Additionally, the problems associated with providing a 
network centric view of potential problems in a network are significantly 
greater than the problems associated with testing an individual network 

15 component for potential problems. Moreover, diagnosing routing table 

problems may involve complex inquiries aimed at identifying routing loops and 
identifying dead end paths, for example. Furthermore, security issues involving 
router access lists can be difficult to. diagnose without a relatively 
comprehensive understanding of the operation of the network containing 

20 routers with such access lists, so that, for instance, a route around a blocked 
host can be tracked. 

Thus, there has been a need for improved network management tools 
that can provide network centric analysis of potential problems and that can 
provide diverse views of network topology in order to enhance a network 

25 manager's ability to manage a network. The present invention meets this need. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a flow chart of the overall data and process flow of the 
present invention. 
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l F'ucess occurring within FIG. 1 
HG. Ib shows the subprocess of Constructing the Tono. 

executed, *e process in Fig lb i s 

Fir , u snpwnasFIG. l e as described above 

FIG lg shows the subprocess of Anni. • • 

described above. 8 ,COrF, S ,fas 

FIG. 1 h shows the suboroce« nf f u» 

PIG li shows the subprocess of importing modified SRO* h , 
lm network, this occurs logically after ,h. . • ROStek "" olhe 

FIG's la-li can run. ' °" the P rocess <* in 
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FIG. 2 shows the object data structure of the "Structured Router Object 
(SRO) a principle data structures of the invention. A set of SROs serve as the 
primary input for all subsequent analysis. 

FIG. 3 shows the object data structure of the "Single Protocol 
5 Topology" object, a principle data structures of the invention that is populated 
in the process shown as Fig lb. It will serve as input to numerous processes as 
shown in FIG. 1 . 

FIG. 4 is a flowchart of the process that creates a Single Protocol 
Topology (SPT) object data structure for a given protocol P given the set of 
10 SROs (FIG. 3) as input. 

FIG. 5 is an annotated topology drawing of a hypothetical network. It 
is referenced by subsequent figures. 

FIG. 6a & b are sample router configuration files for routers in FIG. 5. 

FIG. 7a shows the populated SRO associated with the router 
15 configuration file shown in FIG. 6a, Router 1 (Rl) in FIG. 5. 

FIG. 7b shows the populated SRO associated with the router 
configuration file shown in FIG. 6b, Router 2 (R2) in FIG. 5. 

FIG. 8 is a step-by-step walk through of a Single Protocol Topology 
(SPT) object data structure build routine that is shown in FIG.4. 
20 FIG's 8a through 8j illustrate the values of the SPT for Protocol = IP 

following the execution of steps in FIG. 4 as indicated by annotations on FIG 
5. 

FIG. 8a shows the SPT following Step 1, initialized to its EMPTY 

state 

25 FIG. 8b shows the population of the SPT following FIG. 4, Step 5, with 

the first connection (a subnet) added to the object. 

FIG. 8c shows the population of the SPT following FIG. 4, Step 4 with 
a Pointer added to the first Port Address 
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no. 8d shows a. pop^o,, of lhe SPT fc|low . ng t(K ^ ^ 

SttP 5 ' addine " w ™»«ion to the object data struct™, 

FIG. 8e shows the SPT alterthe second p. of FIG. 4, Step 5, adding 

the next pomter to (ho SPT object data structure. 

Hft 8f shows the .coping through FIG. 4, Step 4 adding tt . remaining 

pointer to the second connection. 

FIG. 8g shows the third pass through FIG. 4, Step 5 adding the third 
and last connection to the SPT object data structure. 

to SPT r ^ SW ^ f ° Urth ^ thrOU8h 4 ' StCP 4 * P^er 

to SPT that pomts to the last port address of the hypothetical network 

configuration. 

FIG. 8i shows the completed SPT object following FIG 4 Step 7 

™* sh °™ *• S " *- »ou,d be created by the process shown in 
fiU. 4 for the case where Protocol = IPX 

th c J IG 9Sh ° WSaneXtenSi0n0ftheflowcto 

the SPT s, to check for the integrity violation of duplicate addresses 

FIG. 10 is a flowchart to check for the integrity violation of overlapping 
subnet masks given an SPT as input. 

FIG. 1 1 is a topology drawing of a hypothetical network shown with a 
Campus View. It supports discussion of the "Create Views" process shown as 

riKJ. lc. 

FIG. 12 shows the object data structure of a Campus View Object 
corresponding to the topology shown in FIG. 1 1 

FIG. 13 is a flowchart of the process that forms a Campus View Object 
given an SPT and SROs as input. ' 

FIG. 14 is a topology drawing of the same network shown in FIG 1 1 
re^esenting,^ 
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FIG 1 5 is the OSPF View Object data structure corresponding to the 
topology shown in FIG. 14. 

FIG's 16a & b shows the SRO object data structures for the routers 
shown in FIG. 14. 

5 FIG. 1 7 shows the SPT object data structure for the network shown in 

FIG 14. 

FIG. 18 is a flowchart of the process that forms an OSPF View object 
data structure given an SPT and set of SROs as input. 

FIG. 19 is a flowchart expanding on the "AreaSet" concept introduced 
10 in FIG. 18 

FIG. 20 is a flowchart expanding on the "How Many Areas Does 
Router Have" question from FIG. 18 

FIG. 21 shows the object data structure of the Multiple Protocol 
Topology (MPT) object, a principle data structure of the invention that is 
15 populated during execution of the process shown in FIG. lb. 

FIG. 22 is a flowchart of the process that populates the MPT obj ect 
data structure taking a set of SPTs (for the different protocols) as input. 

FIG 23 is a flowchart expanding on the process of Step 4 T in FIG 
22,"matching connections with Multiprotocol Connection (MpC) objects"; 
20 FIG's 24a through 24i comprise a step-by-step walk-through of the 

Multi-Protocol Topology (MPT) object data structure build routine. It refers 
to the topology shown in FIG.5 

FIG's 24a through 24i illustrate the values in the MPT object following 
the Step(s) in FIG. 22 each of which is labeled with a number inside a circle . 
25 FIG. 24a shows the MPT object initialized to EMPTY- 

FIG. 24b Shows the addition of the first MpC for protocol - IP following 
FIG. 22, Step 3. 

FIG. 24c Shows the effect of the loop through FIG. 22, Steps 3, 4 t & 5 
adding another MpC and pointers (again for Protocol = IP) to the object 
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FIG. 24d shows the effect of the same loop now finishing MpC's and 

pointers for Protocol = IP. 

FIG 22^? Sh ° WS ^ COmPleted Pr ° t0C01 = IP as follow 

5 FIG. 24f shows the addition of the first IPX element of the example 

following execution of FIG. 22, Step 8. 

FIG. 24g shows the addition of the second IPX element to the MPT 
object again looping through FIG. 22, Step 8. 

FIG. 24h shows the addition of the last IPX element to the MPT as 
1 0. follows the last pass through FIG. 22, Step 8. 

FIG. 24i shows the completed MPT object as would occur at the time 
of FIG. 22, Step 11. 

FIG. 25 shows the Object data structures of the SRO & MPT to 

demonstrate the linkages that inter-relatP th*m *c *u 
, , * inter relate them as they would occur following 

13 execution of the process shown in FIG. lb. 

FIG. 26 shows an annotated network diagram and instantiated SPT 
object data structures that demonstrate a violation of the integrity check that 
finds mismatched protocols during the building of the MPT. 

FIG. 27 shows a flowchart for the process for resolving IP-unnumbered 

~ nS USing C ° nneCti0nS 0fan <«her P-tocol, this process occurs during 
the topology construction phase (FIG. l b) 

FIG. 28 is a topology drawing of a hypothetical network that will be 
referenced along wit, subsequent figures to show how information missing 
^ ^^IPSPTbecauseoftheuseoflP-unnumber.di.fito 

FIG. 29a - 29d show hypothetical Router Configuration Files for 
routers (R3 through R6) shown in FIG 28. 

FIG. 3 0a shows the SRO object for R3 in FIG. 28. 
FIG. 30b shows the SRO object for R4 in FIG. 28. 
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FIG. 30c shows the SRO object for R5 in FIG. 28. 

FIG. 30d shows the SRO object for R6 in FIG. 28. 

FIG. 30e shows examples of the IP and IPX SPT object data structures 
as they would be populated following the execution of the SPT build process in 
5 FIG. 4 for IP and IPX. 

FIG. 3 Of shows an example of the MPT object data structure as it 
would be populated following the execution of the process in FIG. 22 taking 
the SPTs in FIG. 30e as input, and refined with the additional process shown 
as FIG 27 that fills-in information missing due to the use of IP-unnumbered. 
10 FIG 3 1 is a repetition of FIG 4 (a flowchart of the process that 

populates the SPT object data structure) annotated for integration with a 
flowchart for handling the Frame Relay WAN complication to the SPT build 
process. 

FIG. 32 is a flowchart that shows the set of extensions to FIG 3 1 
1 5 required to handle the Frame Relay WAN complication to the SPT build 
process (FIG. 4). 

FIG. 33 is the merged result of FIG's 3 1 & 32 and shows the complete 
set of logic applied by the invention to accurately populate the SPT despite the 
complications introduced when the process encounters the presence of Frame 
20 Relay multi-point WAN. 

FIG. 34 is a topology drawing of a hypothetical network. It is 
referenced by subsequent figures in support of the illustrations related to the 
Multipoint WAN complication discussion. 

FIG. 35 shows a SPT object as would be prepared by a naive algorithm 
25 incorrectly creating pointers for a Frame Relay WAN (FIG 4) without the 
enhancements shown as FIG. 32. 

FIG 36 shows an accurate SPT object for FIG 4 as computed by the 
SPT build algorithm that takes into account Multipoint WAN complication as 
shown in FIG 33. 



WO 97/49214 



PCT/US96/10873 



10 



15 



20 



25 



-10- 

FIG. 37 shows the SRO object for router RI i„ FIG. 34 focusing on the 

Frame Map objects. 

FIG. 38a - d shorn the rou.erconligun.Uon file, f„, each router 
iMra.ec: in Btt 34 (.opoiog, ,o demons,™ *, Frame Re,a y „u Wpoint 

WAN example) 

in FIG " C . 39 ?° U8k ^ *~* "* SeP - by - S,eP " ° f «* 

33 by '^"S "*» °f *i* s and ins.anua.ions of ,he SPT as 
-ch ..en of , he flowchart „ executed. This is par, of .he process occurring in 

rid. lb. 

FIO. 40 i, a flowchart showing ,he process for determining 
and delay mismatches betweer, adjacn, routers. This is an integrity check tha. 
occurs during the phase indicated as FIG Id. 

HO. 41 is a flowchart showing the process for determining the 
extstence of unresolved static routes as coded in router configurations, this is 
an mtegrity check that occurs during the execution of the phase shown as FIG 
Id. 

FIG. 43 is a flowchart of the process for determining access list 
subsumption problems, this is an integrity check app ,i e d during the phase 
shown as FIG. Id. 

FIG. 44 is a flowchar. showing .he process for calculating routing table 
+mm taking a SPT and SROs as iaput, i, occur, during K ecu,ion of the 
Phase shown as FIG. if Lis an al.Cma.ive method ,0 ca P .„ring ,ive rou,i„g 
tables from the network as shown in FIG. le. 

FIG. 44a shows the first modification made to the process shown in 
FIG. 44 to efficiently handle loops encountered white creating routing tables 
FIG 44b shows a companion modification to that shown in FIG 44a 
that efficiently handles loops encountered while creating routing tables" 
_ FIG 45 Sh ° WS the ^ta structure of the Routing Table object 
ThlS ° bjeCt iS P ° PU,ated duri "g *her of the processes shown as FIG's leorf. 
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lt becomes input to the process shown in FIG. lg which evaluates integrity 
checks that use routing tables as input. 

FIG. 47 is a topology drawing of a hypothetical network and a 
definition of the Current Path Set (GPS) concept. It is used to provide 
5 background to enhance the readers understanding of the concepts explained in 
FIG's 48 through 56. 

FIG. 48a, 48b & 48c comprise a flowchart that describes the process 
of finding paths from a Source Address to Destination Address, which is used 
as a subroutine as part of the phase shown as FIG. lg. 
10 FIG. 50 is a flowchart of the subprdcess of matching routing table 

elements per FIG. 48b Step 12. 

FIG. 5 1 is a hypothetical network topology map annotated with port 
designations and subnet addresses to be referenced in subsequent FIG's 52 
through 56. 

1 5 FIG. 52 shows a SPT object data structure corresponding to the 

topology shown in FIG. 51 

FIG. 53 shows part of a routing table object data structure for router 
Rl in FIG. 51. 

FIG. 54 shows part of a routing table object data structure for router 
20 R2 in FIG. 51. 

FIG. 55 shows part of a routing table object data structure for router 
R3in FIG. 51. 

FIG. 55a shows part of a routing table object data structure for router 
R4 in FIG. 51. 

25 FIG. 56a - f shows a step^by-step walk-through of the flowchart in FIG. 

48a,b,&c (a flowchart for finding Paths between Source Address and 
Destination Address) using the topology illustrated in FIG. 51 as the example's 
input. 
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FIG. 57 shows the object data structure of the Access List object in 
attribute form. 

FIG. 58 is a flowchart showing the process of determining whether or 
not an element is blocked by an access list. This logic is invoked during the 
process shown as FIG. Ig. 

FIG. 59 is a flowchart that shows the modifications to the flowchart in 
HG. 48 (which determines network connectivity ) to take into account Input 

Access Lists. 

FIG. 60 is a flowchart that shows the modifications to the flowchart in 
FIG. 48 (which determines network connectivity ) to take into account Output 
Access Lists. 

FIG. 61 is a flowchart of a modification the invention applied to the 
process shown in FIG 48b to handle paths addressed to a router. 

FIG. 62 is a flowchart of a process which is a variant to the process 
shown in FIG 48 a-c to handle a path starting from a router, instead of a host 
address. 

FIG. 67 is a topology rendering showing implicit RSRB connections 
that preface discussion and subsequent figures to show how the invention 
evaluates the quality of connectivity given instances of level 2 connectivity (i.e., 
bridging - or specifically Remote Source Route Bridging (RSRB)). 

FIG. 68a is a sample router configuration file for Router Rl i n FIG. 67. 
FIG. 68b is a sample router configuration file for Router R6 in FIG. 67. 
FIG. 69 shows the SRO excerpts focusing on the RSRB attributes for 
Routers Rl and R6 having configs in FIG's 68a and 68b. 

FIG. 70 shows a flowchart that computes the "RSRB/DLSw remote 
peers connectivity" integrity check. This is part of the phase shown as FIG. Ig. 

FIG. 71 shows a flowchart that computes the "BGP remote neighbors 
connectivity" integrity check. This is part of the phase shown as FIG. Ig 
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FIG. 72 shows a flowchart that computes the "User supplied 
connectivity requirements" integrity check. This is part of the phase shown as 
FIG. lg. 

FIG. 73 shows a flowchart that computes the "Routing Loops" integrity 
check. This is apart of the phase shown in FIG. lg. 

DETAILED DESCRIPTION OF THF PRF FERRFD F.MRQDTMFNT 

The present invention comprises a novel method and apparatus for 
network management. The following description is presented to enable any 
person skilled in the art to make and use the invention; Descriptions of specific 
applications are provided only as examples. Various modifications to the 
preferred embodiment will be readily apparent to those skilled in the art, and 
the general principles defined herein may be applied to other embodiments and 
applications without departing from the spirit and scope of the invention. 
Thus, the present invention is not intended to be limited to the embodiment 
shown, but is to be accorded the widest scope consistent with the principles 
and features disclosed herein. 

The purpose of the present invention is to assist network managers, 
administrators and/or planners manage routed networks for which they are 
responsible. "Routed Network" herein means a set of logically connected 
devices, each of which can operate as a switching device at level 3 in the OSI 
modeL A presently preferred embodiment of the invention is architected to 
operate in connection with any of the following environments: a live network 
to manage; proposed network configuration information existing for a planned 
network to be analyzed; a live network along with configuration information 
for a set of planned changes; or, multiple li ve networks to be merged. 

A high level view of Figure 1 shows an overall process, in accordance 
with a preferred embodiment of the invention, for obtaining network 
information from a variety of sources, putting this information into the 
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■nvenfon's data base, rendering different views of the network, applying 
vanous integrity checks, using this information to decide if there are problems 
needing to be addressed, making corrections if there are problems, then either 
downing these corrections to the network, or, putting these corrections 
back ,n the data base for reiterative analysis. In sum , thi? process ^ ^ 
user to: capture network configuration information, analyse it, find problems 
■n the network's configuration, evaluate that information, proactively vaHdate 
prospective changes, and, either download the configuration back into the live 
routed network or reiterate the analysis based on the original configuration 
w>th the prospective changes applied. A key factor is that the invention enables 
proactive validation of a planned network or changes to an existing one A 
network manager, therefore, can better design, manage and modify routed user 
and manage a routed network which is devoid of, or has fewer problems than 
without the invention. 

- Throughout the following discussion it will be presumed that line by 
line coding involved in implementing the processes and structures disclosed 
herem is well within the abilities of one skiUed in the art and so is not described 

herein. 

Each sub-figure (la - li) in Figure 1 relates to a discrete portion of an 
overall analytical process in accordance with a current implementation of the 

invention. 

Figure la represents the process for capturing information about each 
of the routers in the live or planned network from in a format actually used by a 
grven router. Router devices are well known in the art. They a* switching 
devices at level 3 in the OS1 model. For Cisco Systems, inc. products for 
example, this input is an ASCII text configuration file in a proprietary language 
(IOS, TM). For Bay Networks Corp. products, for example, this input is the 
bmary configuration data base provided as output from a commercially 
ava,lable computer program such as Site Manager (TM) program, for example 
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The process represented in Figure la parses the input data from, for example, 
configuration file, the manager output, or MIB data capturing a router's 
configuration, as described above, and fills-in default information as necessary 
to populate object data structure referred to herein as the Structured Router 
5 Object (SRO). 

Figure lb represents a process of forming a "topology" from the SROs. 
In the presently preferred embodiment of the invention, there are several types 
of consitutent components of the topology. One type of component comprises 
is a set of objects called SPTs, for "Single Protocol Topology". An SPT is 

1 0 produced for each protocol running on a network, such as IP, IPX and 

Appletalk™ Running multiple protocols in a network has become a common 
practice in networking. Each SPT indicates for a given protocol which routing 
device ports are running the given protocol and which ports are logically 
connected over the protocol. Another type of component comprising the 

1 5 topology is implemented as an object referred to herein as an MPT, which 

stands for "Multiple Protocol Topology". In the present embodiment, there is 
one MPT per network. The MPT includes information that indicates how the 
SPTs relate to each other. For example, if a network routes both IP and IPX, 
both an IP SPT and an IPX SPT will be created, and they will be cross- 

20 referenced to each other to form an MPT. 

The novel MPT can be used, in conjunction with novel processes in 
accordance with the invention, to determine whether network protocols have 
compatible addressing. 

Processes in accordance with the invention can determine when two 

25 topologies have incompatible addressing and can identify the source of the 
conflict, such as the parts and protocols involved in the conflict. More 
particularly, during the process represented by Figure lb, logical topologies are 
produced for the different protocols that run on a live or planned network. 
These topologies are called SPTs and are produced from the SROs. Once 



WO 97/49214 



PCT/US96/10873 



10 



15 



20 



25 



-16- 

SPTs have been constructed for the various protocols, they are interrelated 
with each other to form a structure called an MPT. The MPT can be used to 
identify conflicts between protocols represented in the different SPTs The 
SPTs and the MPT provide valuable diagnostic information that can be useful 
in identifying network problems. 

The processes represented by Figure lb produce "level 3 logical- 
topologies. A level 3 logical topology is defined by the OSI model. Figure 1c 
represents a process which provides more abstract or "higher level" views or 
representations of a network. Examples of these more abstract views are 
OSPF and BGP views. These more abstract views can be useful to a network 
manager or designer who wishes to observe only certain abstractions or views 
of a network. Modern networks are extremely comp l ex creations. Higher 
level/more abstract views enable the persons responsible for maintaining 
designing or modifying networks to better visualize the network they are 
operating upon by removing from the view components that are not relevant to 
the immediate task at hand or grouping devices. 

Using the object model formed in Figure lb, (i.e., integrated 
SRO/SPTs/MPT), processes represented by Figure Id determine whether there 
are potential problems in the actual or proposed network represented by the 
object model. The conventional approach to trouble-shooting a routed 
network typically involved a user evaluating routers one by one to determine 
whether there are problems with individual routers' configurations. A router 
configuration is a specification interpreted by a router's operating system that 
HKhcates precisely how a router is to process and respond to all types of data 
packets, and how it generates, receives, and processes messages that are sent 
between itself and other routers to construct routing tables. The object model 
produced in accordance with the processes of Figure lb enables a more 
network-centric view which allows a user to identify at not just problems in a 
single router, but also problems that relate to two or more routers An 
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important feature of the process represented by Figure Id is the application of 
numerous novel integrity checks which can identify problems in not just 
individual routers, but across routers spanning the whole network. "Integrity 
Check" as used herein means the result from a procedure that determines 
5 whether there is a critical or potential problem in the network configuration. 

The differences and relationship between the views produced according 
to the processes of Figure lc and the integrity checks represented by Figure Id 
are as follows. Thus, in the current embodiment, high level/abstract views may 
be used for rendering images of various protocol topologies; while integrity 

10 checks ordinarily represent information in a more textural form. A user can 
employ both views and integrity checks to diagnose potential problems with a 
network. More to the point, views set a graphic or visual context for 
interpreting textual reports of integrity check violations. For example, an 
integrity check violation may identify a network component or components 

1 5 such as a router or a subnet; while the view permits a user to visualize where 
the component or components resides in the network and its relation to other 
network components. 

Referring now to Figure lg, there are multiple types of integrity checks 
that can be performed given routing tables as input. A routing table is a table 

20 with rows (elements) indexed by level 3 destination addresses and/or level 3 

"summary addresses", which refer to ranges of addresses; if a router receives a 
packet that is not filtered on the incoming port, (and the packet's destination is 
not the router itself), it will look for a routing table element that matches the 
packet's destination. If no match is found, the packet is dropped. If there are a 

25 number of matches, then the element with the narrowest range (i.e., most 

specific address range) is used. The matching element indicates what port to 
send the packet out of and either a next hop router or the fact that the port is 
connected to the local area network (LAN) where the destination resides. The 
packet is sent out this output port unless there is an output port filter that 
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user can observe the problems in his or her network, and consequently may 
make modifications to the object model (i.e., the topology comprising 
SRO/SPTs/MPT). Once the user makes changes he or she has a number of 
alternatives. One alternative, represented by Figure li, is to make the changes 
5 and download those changes directly into a live router network by providing 
the information on the SROs to live routers in a live network. Another 
alternative, represented by the feedback path that includes the "what if 
Analysis" comment, is to modify the SROs in the object model and reiterate 
through the process steps described above in order to analyze and trouble- 

10 shoot the proposed network changes represented in the updated SROs. 

A significant advantage of the invention is that the information in the 
object model (SROs/SPTs/MPT) can be both used for analysis (creating views 
and running integrity checks for example) and for actual download to a live 
network. This advantage is achieved in the preferred embodiment by storing 

15 router configuration information in executable form in the SROs. the term 
"executable" as used herein means a state of representation of router 
configuration that contains sufficient detail so that it can be translated into a 
form that a router can directly execute. 

Thus, Figure 1 shows the overall process, in accordance with a present 

20 embodiment of the invention, of obtaining information from a network, putting 
it into a data base, applying different types of integrity checks, rendering 
different views, using this information to determine if there are problems, 
making corrections, if there are problems, and either downloading these 
corrections to the network or putting these corrections back in an object mode 

25 data base for further analysis. Consequently, a user can capture an existing 

(live or modeled) network configuration, analyze it, find problems, evaluate the 
problems, proactively validate changes before downloading the changes back 
into the network. An important factor here is that such proactive validation 
permits making validated changes to a routed network without impacting 
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operation of a live network: changes can be planned and tested before 
downloading to a live network. 

As mentioned above, an important factor distinguishing the present 
implementation of the invention from conventional network analysis tools is the 
use of an object data model is both structured and executable, the network to 
be automatically analyzed using the processors represented by Figures Id 
Figure 1c and in Figure Ig. The executable aspect of the object model means 
that the model contains sufficient detail to enable information contained in 
SROs to be readily imported into live network routers. 

The advantages of the invention can be better appreciated, for example 
by considering the prior network tool called, Cisco Works, whose purpose is ' 
configuration management. CiscoWorks deals with the uninterpreted text files 
(Cisco's Configuration Files). CiscoWorks permits the user to load these files 
and make textual modifications, but the user still is at risk of introducing syntax 
errors, for instance, since changes are not validated before the user downloads 
them to the router. In contrast, the processes and structures employed in the 
cmrent embodiment of the invention perform automated validation of changes 
because they use st ructured objects (SROs) representative of the changed 
configuration. 

Another earlier exemplary product that performs network analysis is 
produced by Make System and performs network analysis. The router objects 
in the earlier Make Systems tool, however, are not executable. In other words 
the Make Systems product can not automatically download configurations 
from a database to the live routers without requiring a user to manually add 
configuration detail that the routers require in order to operate. Thus, output 
from the Make Systems product is not designed for automatic input of 
configuration information to live network routers, With the Make Systems 
tool, problems are reported and it is up to the network managers versed in the 
command set(s) of Bay Networks Site Manager and/or Cisco System's IOS to 
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select the appropriate router configuration commands to correct the indicated 
problems, reload these changes to each affected router in the network and then 
run Make's "discovery" process to generate a data model for the analytical 
process to be run again. As used herein, "discovery" means a live process 
5 performed on an actual network that identifies elements and their connections 
in the actual network, which relies on the elements and their ports being 
operational during the process. Contrast the difficulty and potential 
inexactitude (room for human errors) of that process against the ability of the 
present embodiment of the invention to assist the user in identifying potential 
1 0 problems via views and integrity checks, automatically generate executable 
configuration fiies and before implementing those changes to a live network, 
check the proposed changes before then automatically loading the fully 
executable files to the live network for both Cisco Systems and Bay Networks 
products. 

15 Figure 2 depicts the Structured Router Object which, in accordance 

with a presently preferred embodiment of the invention, we will refer to herein 
as the SRO. The SRO is a data structure encoding the contents of a single 
router's configuration that are relevant to a given network analysis at hand. 
We refer to this data structure as "structured" to convey that it is composed of 

20 interrelated attributes and to distinguish it from such constructs as a text file 
containing a router's configuration which is amorphous rather than structured. 

Figure 2 illustrates a sufficient subset of the components constituting an 
SRO to enable one skilled in the art to practice the invention. In an actual real- 
life SRO there are many more components. A SRO, as well as other structured 

25 objects referred to in this disclosure, can be described in the hierarchical fashion 
by starting with top level attributes and then explaining and illustrating how 
these attributes are further decomposed into lower level attributes. In the 
disclosure that follows, structured objects will be presented in two different 
ways: i) in attribute form, which is a description of an object's interrelated 
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attributes that omits the exact values of the attributes and ii) in instantiated 
form, which is a description of both the attributes and their (exemplary) exact 
values. Figure 2 provides an attribute form description of a SRO. 

In the present implementation of the invention, objects are produced 
using C++" programming language techniques. However, other programming 
languages could be used to produce the structures. This is considered to be 
well within the ordinary level of skill in the art, and, therefore, is not explained 
in detail herein. 

Referring to Figure 2, at reference numeral 1 there is shown an 
attribute, which is host name. This is a unique name for identifying the router. 
Looking down the structure, the next high level attribute is Ports. The value of 
this attribute is a list of objects, each one having it own structure. Each of 
these objects, such as the one labeled 2, is called a Port Object. A router 
consists of a set of physical ports, each having its own configuration. Each 
router's port in the invention is represented by a Port Object, which consists of 
a list of structured objects itself Referring to Figure 2, we see that there are 
ports 1 through N, representing N different ports or the router. The number of 

ports on a router depends on the type (i.e. make and mode! number) of the 
router and how it is physically configured. For an individual port, (labeled as 
(2) in Figure 2), there area number of attributes. The first is media type, 
whose value can be Ethernet, Token Ring, Serial, Serial Link, FDDI, etc! We 
also identify a number, which is used to distinguish between two ports of the 
same media type. The next attribute is called encapsulation, which indicates 
what type of encapsulation is running on the connected media. An 
encapsulation example is Frame Relay on a Serial media to distinguish it from a 
HDLC serial. Further attributes include: bandwidth - which is a scalar metric 
used by the IGRP routing protocol that relates to bandwidth of the connecting 
media. The attributes also include delay - which is a scalar metric connoting 
the speed of the connected media and is also used by the IGRP routing process 
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The next four attributes shown in Figure 2 (labeled as (3)) are attributes related 
to access lists. Access lists are used to filter traffic coming in and out of the 
router. Typically access lists are used for security purposes and routing 
purposes. Access lists are used to block or permit packets with either specific 
5 addresses or ranges of addresses, to be received or transmitted by a router 

The first access list attribute illustrated in Figure 2, (AccLstIP), stands for input 
access list, IP. This access list item is used to filter input IP packets. The 
attribute OutAccLat refers to filtering output IP traffic. Similarly, the attributes 
AccLstlPX and OutAccLatlPX refer to filtering input and output IPX packets. 

10 It should be appreciated that access information for other protocols, such as 
AppleTalk, has been omitted from Figure 2 for simplification. 

The last attribute under the port object is Port_addr. Each port has one 
or more addresses assigned to it. The Port_addr object has an attribute called 
"protocol" which refers to a particular address' level 3 protocol, such as IP, 

1 5 IPX, and, AppleTalk. The address attribute gives the exact address. Port 
Addresses serve as building blocks for forming the topology information. 

The SRO structure accommodates multiple port address per port as any 
given port on a router may be running multiple protocols. For instance, 
consider a port configured for both IP and IPX. Typically such case, one 

20 would have both an IP and IPX address for this port. Another reason for 

having multiple port addresses is that routers produced by Cisco Systems, for 
example, employ a concept called primary and secondary IP addresses where 
the user could address the same physical port with multiple IP addresses. 

Before discussing the next high level attribute of the SRO, Protocols, 

25 we consider the difference between this high level attribute and the subobject of 
the Port Object similarly named Protocol. The latter refers to the protocol(s) 
"running" on the particular port. These port-related protocols define the type 
of the packets of data that come in and out of the router's ports (i.e., IP, IPX, 
AppleTalk, DECnet, etc.) By contrast, the high-level attribute Protocols refers 
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to the routing protocols such as RIP, IGRP, OSPF, EIGRP and BGP, that the 
routers use to exchange information and build up the routing tables. ' 

The attribute, Protocols, comprises of a list of objects describing each 
routing protocol running on the router. The value of the "Type" attribute of a 
5 protoco. object, labeled 4 in Figure 2, represents a type of routing protocol 
(e g., RIP, OSPF, IGRP, etc.), and for some of the protocols, additionally a 
number. This number is used because a router could run multiple copies of 
some protocols, such as OSPF or IGRP, on the same router. The next 
attribute is Net Addresses. Typically a routing protocol is running on certain 
10 interfaces (i.e. ports) on the router. Each element in the list Net Addr is an 
address capturing the ports (port addresses) the associated protocol is nmning 
over. This specification greatly simplifies the Protocol object; a current 
implementation of the invention includes over 50 attributes associated with 
protocols. One skilled in the art will appreciate how to incorporate such router 
15 attributes into an SRO based upon this discussion. 

The next high level attribute of the SRO is Static Routes. The value of 
the Static Routes attribute is a list of objects. Each one of these objects 
labeled 5, refers to what is called a static route. There are basically two 
approaches to produce routes in a routing table. One approach is to run the 
routing protocols discussed earlier. The other approach is to directly code 
routes into the routing table. This latter approach involves specifying a set of 
static routes. A static route is identified by specifying a destination address 
Dest-Addr a next router address, which tells the router where to send a packet 
matching Dest-Addr which is discussed below. 

The next high level attribute of the SRO is Access Lists, whose value is 
a hst of objects, each object representing an access list. We earlier referred to 
access lists when we talked about port objects. For example, at the reference 
numberal 6 we refer to an "input" IP access list. At reference numeral 6 the 
SRO does not contain a whole access list, rather at this point in the structure 
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there is a number referencing an access list. Each access list object in the list 
Access Lists contains a full description of the access list and a number (see 
reference nuniberal 7) used for reference elsewhere (such as at InAcclstIP). 
The Elements attribute in an access list refers to a list of patterns which 
5 describe what addresses to permit and deny. 

Still referring to Figure 2, we see an example of the next high level 
attribute called SRB J3ridgeJ3roups. SRB stands for "Source Route 
Bridging," which is a mechanism for transporting traffic typically associated 
with Level 2 in the OSI model. There is also a variant of SRB bridging 

1 0 implemented in routed networks where SRB traffic can be encapsulated over 
an IP backbone, SRBJBridge_Group and RSRB-Peer objects are specified in 
the SRQ. Each bridge group has a group number associated with it and a list 
of peers. Briefly, a peer is an object with an attribute specifying encapsulation 
type, which indicates what encapsulation method is being used to transport 

1 5 SRB frames. One example is TCP encapsulated; another example, which Cisco 
Systems provides, is FST encapsulation. The other attribute of a Peer object 
may indicate the address of another router in the network where encapsulated 
SRB data should or potentially should be sent. 

Thus, to summarize Figure 2, the information in the SRO captures a 

20 router's configuration. The information put into an SRO could be gleaned 

from a MIB or from a router configuration file, or from information regarding a 
planned or hypothetical network. A SRO structure, in accordance with the 
present embodiment of the invention, can serve as a neutral repository for 
configuration information from virtually any router vendor whether they use 

25 binaries or configuration files. 

Figure 3 represents a Single Protocol Topology (SPT) object in 
attribuie form, in accordance with a presently preferred embodiment of the 
invention. An SPT is formed for each of multiple Level 3 protocols (e.g. IP, 
IPX, AppleTalk). The SPT for a given protocol "P" represents a logical view 



WO 97/49214 



PCT/US96/10873 



10 



15 



20 



25 



-26- 

of the topology from the perspective of that given protocol. The data structure 
in Figure 3 indicates which router ports are configured to run protocol "P» and 
how each of these ports is logically interconnected with other ports that run 
protocol "P." A SPT for protocol P has a top level atomic attribute, Protocol 
that is set to »P,« (e.g., IP, IPX, AppleTalk, etc.) and a top-level attribute 
GONNs (labeled 1 in Fig. 3), which is a list of objects each called a 
Connection Each Connection identifies a list of router ports and their 
addresses, all of which are configured to receive and transmit packets of 
protocol type P and are directly connected from a Level 3 perspective with 
respect to protocol P. As an example, for an IP SPT, all the ports listed in the 
Connection will belong to the same subnet. We can say that all the ports in a 
Connection are directly Connected from a Level 3 perspective to clarify that at 
a lower level, at Level 2, these ports might not be directly connected. For 
example, there may be bridges, LAN or WAN switches between these ports. If 
they are also directly connected from a Level 2 perspective, then one could 
necessarily associate a single media type with the connection such as serial 
links, Ethernets, token rings, FDDI's, etc. 

Figure 3 shows that each Connection object consists of a list of 
pointers. Each of these pointers refers to a port address in a specific router. 
When representing a pointer in a SPT Connection we will use the form 
(Rt,Po,Pr) where Rt refers to a router's host name, Po refers to a router's port, 
and Pr refers to a protocol annotated by an index which is described below 
For example, (Rl ,S0,IP1 ) refers to the first IP address assigned to port SO (or 
in long form, Serial 0) on the router with host name RL This pointer links to a 
Port Address object in a SROs (see the reference numeral 12 in Figure 2) in a 
network under consideration. 

In giving the description of IP L we said the "first" IP address- the 
reason we said "the first IP address" is that it is possible to assign two or more 
IP addresses to the same physical port. Cisco Systems, for example, refers to 
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this configuration feature as assigning secondary IP addresses (as well the 
mandatory primary EP address) to a router port. Although the actual 
implementation of the invention makes a distinction between primary and 
secondary addresses, this disclosure does not make this distinction, and simply 
5 states that a port has a set of IP addresses. Thus, in general a port may have 
one or more addresses for any protocol. Now suppose that two ports, SI and 
S2 t respectively, on routers Rl and R2, are physically connected through a 
serial link, and both these ports have two IP addresses assigned. Furthermore, 
assume that the first IP address on SI, whose pointer would be (R1,S1,IP1) 

10 belongs to the same subnet as the first IP address on S2, whose pointer would 
be (R2,S2,IP1) also suppose that the second IP address on SI, (Rl ,S1,IP2), 
belongs to the same subnet as the second IP address on S2, that is (R2,S2,IP2) 
In this case, although there is only one physical medium connecting the two 
ports, that is a single serial link, the IP SPT containing routers Rl and R2 will 

1 5 have two (logical) connections for this one serial link. 

Thus, to summarize Figure 3, a Single Protocol Topology, SPT, is a 
data structure that can be produced for each Level 3 protocol such as IP, IPX, 
and AppleTalk. A SPT for some protocol P is a logical view of the topology 
from the perspective of protocol P. This data structure indicates which router 

20 ports are configured to run protocol P and how each of these ports are logically 
interconnected wiih respect to the protocol. Although the network under 
analysis may contain Level 2 devices, such as bridges and switches, but at a 
Level 3 view, these devices are "invisible" meaning, for example, if there is a 
switch between two router ports in the Level 3 view, the ports are still viewed 

25 as being directly connected, A SPT differs from an SRO in that, while a single 
SRO captures the configuration of a single router, a single SPT captures the 
logical interconnections of a set of routers. 

The following discussion describes an earlier tool by Make Systems, 
and explains some significant differences in the process that tool employs to 
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create an SPT-Iike data structure and how that structure differs from the SPTs 
of the present embodiment of the invention, 

The Make Systems' internetworking product can use a "discovery- 
process, which requires a live network. Starting at a seed router (an arbitrary 
startmg point on the live network), the tool reads the router's routing tables for 
the next hop addresses to the neighbor routers. This process continues in a 
breadth first manner to find the set of interconnected routers. This process also 
uses mformation, such as ARP (Address Resolution Protocol) information and 
configured interface speeds, in determining the valid router connections. 

An important distinction is the fact that the Make Systems process is a 
discovery process. It is inherently a live process which relies on live routers 
and their interfaces being operational. In contrast, the current embodiment of 
the invention SPT topology formation involves processes that can take place 
"off-line." Specifically, in the current embodiment of the invention, on-line 
configuration information typically is captured in one pass. After it has been 
captured, the formation of the SPT topology occurs off- line. In contrast the 
Make System uses an on-line discovery process during topology formation An 
advantage inherent in the approach to SPT formation in accordance with the 
invention is that it not as susceptible to errors in determining the proper 
configuration due to network devices and router ports being in a temporarily 
failed state. 

Another discriminating factor with respect to SPTs formation is the fact 
that earlier tools typically focused mainly on producing IP topologies because 
discovery is typically oriented towards IP. Some earlier tools also looked at 
IPX , but one of the disadvantages of discovery is that for a given protocol 
one needs a certain level of instrumentation for that protocol to rind the 
topology. Another disadvantage is that one may need to use different discovery 
techniques to discover an IP logical view versus IPX or versus AppIeTalk In 
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contrast, an SPT formation process in accordance with the present invention, 
handles all protocols using the same algorithm. 

Figure 4 is a generic procedure for forming a SPT for some protocol P 
from the set of SROs corresponding to the routers spanning the network. 
5 When we say "generic" we mean that this procedure, aside from a function 
called the SUBNET function, referenced in by numeral (3), is the same 
regardless to whether P refers to IP, IPX, AppleTalk or DECnet, etc. Figure 4 
provides a flowchart of the SPT build process of the presently preferred 
embodiment of the invention. At Step (1) the Output SPT p is initialized (set to 
1 0 empty) to indicate that initially there are no connections in the SPT for 
protocol P. 

Step 2 initializes a variable PA to the first port address of protocol P in 
the list of routers. Given the set of SROs that contain router information for the 
network under consideration, the invention arbitrarily orders this set in an 

1 5 ordered list. 

Step 3 asks whether the subnet function (which will be different from 
protocol to protocol) associated with port address PA already in the SPTp". 
Initially, since SPT p is empty, the answer will be "no," and the algorithm moves 
to step (5). At Step (5) a new Connection object with subnet attribute set to 

20 SUBNET p (PA) is added to the SPT p . A "Connection" object represents a 

particular connection between a set of router ports. If the answer was !, yes" at 
Step (3), (in other words, SUBNET p (PA) is already in the SPT), then the 
invention would skip directly to Step (4). Next, at step (4) a pointer is added 
under the subnet to that port address PA. Next, after step (4), go to Step (7) 

25 and ask if the last port address has been reached. If so, the process is finished 
because all the port addresses have been processed . If the answer is "no" then 
Step (6) is reached where PA is assigned the next port address and the process 
repeats itself by looping to Step (3). 
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The definitions for the subnet functions are given in the box on the 
bottom of Figure 4 For IP, the input to the Subnet function is 3 2 bit address 
Al and 32 bit mask Ml configured on a port; the subnet function returns an 
address mask pair, where the address-part is formed by applying the mask Ml 
5 using bit-wise and to address Al; the mask given as output is simply Ml. In the 
examples in this patent, we use the address-part of the subnet as shorthand for 
the entire subnet. For example 10.10.0 0 is used for [10. 10.0.0 255.255.0.0]; in 
general this shorthand cannot be used, but if the masks used as either 255 0 0 0 
255.255.0.0 or 255.255.255.0 and the zero subnet is not allowed, one can infer 
1 0 the mask from the address-part. 

The subnet functions for IPX and AppleTalk are trivial. For IPX, given 
the IPX network number as input, subnet returns this number as being the 
"subnet". Similarly, for AppleTalk, given lower and upper bound for a cable 
range, the subnet function simply returns this range as output. 

Thus in summary, the procedure iterates through all the port addresses 
in the set of routers and adds a pointer to each port address into the SPT 
structure grouping it with other port addresses belonging to the same. This 
basic SPT formation process is modified in practice to handle complicating 
factors that may arise in networks, such as, multi-point Wide Area Networks 
(WAN's), like Frame Relay, which is described later in this disclosure. 

Figure 5 is a generalized block diagram of a simple example network 
that shall be referenced in a number of subsequent figures. In this network, 
there are two routers, Rl and R2. These two routers are directly connected 
through a serial link. In this and subsequent figures, ports are designated by an 
abbreviation for media type and a number such as "EA.» on router Rl, which 
means Ethernet 0. On Rl's E.O. port, which is in the left of the diagram, we 
see that it connects to a symbol, labeled (1), which refers to an ethernet. Also 
associated with the ethernet are two numeric designators - "10.30.0.0", which 
is the IP subnet number of this ethernet in standard IP octet notation, and 9C 
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which is the IPX network number associated with the same ethernet. In other 
words, there is one ethernet designated at (1), but it has an IPX network 
number 9C and IP subnet number 10.30.0.0. Traversing the drawing from left 
to right, we see port SO (Serial 0) on Rl which is connected to a line that 
5 designates a serial link with HDLC encapsulation. Following to the other side 
of the link, we see the port SO on router R2. We can say that Router Rl , 
through a serial link, is connected from port SO to Router 2 through Router 2's 
port SO. For serial links, like ethernets or other LANs, we can identify both an 
IP subnet, which in this case is 10. 1 0.0.0 and an IPX network number, which is 

10 7 A. Router R2 includes port Ea. (for Ethernet 0) which is labeled (2). This 
portEO at (2) has IP subnet number 10.20.0.0 and IPX network numbered 98. 
In this example, we show a network where both IP and IPX are running on all 
interfaces. It should be appreciated that there may be networks in which 
different protocols run on different interfaces. For example, an interface might 

1 5 be running jiist one protocol or running none at all. Also, an interface could be 
running other protocols, such as AppleTalk and DecNet 

Figure 6A shows the text configuration file for Router Rl and 
Figure 6B shows a text configuration file for Router R2. See, Cisco Systems, 
Inc. "Configuration File Load Commands", Router Products Command 

20 Summary, pp. 6-584, Cisco Systems, Inc., 1992-1995. Figure 7A illustrates 
the SRO that corresponds to Router Rl's text file, and Figure 7B shows the 
SRO that corresponds the text configuration file shown in Figure 6B. 

Briefly stated, a text configuration file is put into SRO form using 
standard parsing techniques. In addition, certain default values also are entered 

25 into the SRO. There is default information that is implicit in the configuration 
file. By omission, attributes still have values. As an example, refer to 
Figure 6A and note where we designate (1), a bandwidth statement for Serial 0 
Router Rl . Refer now to Figure 7A; at the point that is marked (1) is an 
associated bandwidth value of "1000". This bandwidth statement was 
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explicitly coded in Figure 6A, and consequently was parsed and was explicitly 
put into the SRO of Figure 7A. In contrast, note in Figure 6A the version 
labeled (2), which is interface Ea. for R2. In this case, there is no bandwidth 
statement. Referring to Figure 7A at the point marked (2), note in the SRO the 
5 bandwidth is assigned the value 1 GOO. The fact that the bandwidth at (2) and 
the one labeled (1) are both 1000 is just an artifact. By default, each of the 
different media, such as ethernet have bandwidth settings, which are the default 
values. These are values, for example, that a Vendor such as Cisco Systems 
makes public in documentation. Another example of default values is apparent 
1 0 in Figure 6A. No delay specification for either of the interfaces is coded in 
Figure 6A, but referring to Figure 7A at the regions labeled (3) and (4) delay 
parameters are specified. These were inferred knowing that Port [1] is an 
ethernet, which has a default delay of 100, and that Port [2] is a serial interface, 
which has a default delay equal to 2000. 
1 5 Figures 8 A through 81 show a walkthrough of the flowchart in Figure 4 

(a depiction of the process for constructing the SPT for a given protocol). For 
this walkthrough, the inputs are the two SROs given in Figure 7A and 7B. In 
this case, we will be producing a SPT for protocol IP. In the walkthrough, we 
will be referring to the steps which are numbered in Figure 4 and discussing 
20 what happens at each step. The result will show the incremental build of the 
output, an IP SPT for the SROs of Figures 7A and 7B. 

In Step (1 ) the SPT is initialized. Figure 8A shows the SPT at this 
point; protocol is set to IP and there are no connections. 

In Step 2 the variable PA, which refers to a port address, is assigned the 
25 first port address (referring to Figure 7A, the port address marked (5) in the 
diagram). Note that the port address assigned has two ports 10.30.7.2 - which 
is the address - and 255.255.0.0, which is the mask. 

Step (3) asks the question whether the subnet associated with PA is in 
the SPT. The subnet for this PA is 10.30.0.0. The conventional approach to 
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applying the subnet function for the IP protocol follows a simple rule: for each 
of the four octets in the address apply the corresponding mask octet using the 
bit-wise AND operation. For the special case when the mask octets are Os and 
255s, we can use the rule: if there is a 255, it means use the corresponding 
5 octet - if there is a 0 that means ignore it (i.e. "zero out") the corresponding 
octet. Thus, given PA set to 10.30.7.2 255.255.0.0, we use the first to octets 
and ignore the last two, yielding 10.30.0.0; See, Corner, Douglas E., 
"Implementation of Subnets with Masks", Internetworking with TCP/IP, pp. 
273-274, Prentice Hall Inc., 1991. 
10 Since the STP at this point is empty the subnet, 10.30.0.0 is not in this 

SPT. Thus, the answer to the question in Figure 4, Step (3) is "no", and the 
process moves to Step (5) where the process adds a connection Conn[l] with 
subnet 10.30.0.0 to the SPT. Figure 8B shows the state of the SPT after this 
operation (Step 5). 

15 Step (4) adds a pointer to the current port address (referred to as 

R1,E0,IP1) under the connection that is labeled 10.30.0.0. Figure 8C shows 

the result after this step. 

Step 7 asks whether we reached the last port address; In this case, we 

have not - there is three more to process - so the proceeds to Step (6). 
20 In Step (6) the variable PA is set to the next IP port address, which is 

the port address labeled (6) in Figure 7A. After Step (6), processing moves 

back to Step (3). 

At Step (3) the process computes the subnet for this new port address; 
- in this case, the subnet is 10,10.0.0 which is not in the SPT - so the answer to 
25 Step (3) is "no". 

The process proceeds to Step (5) and adds a new connection, whose 
subnet is 10. 10.0.0, to the SPT that it is building. Figure 8D shows the state of 
the SPT after Step (5). 
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Next, processing proceeds to Step (4) where a pointer is added to PA 
the pointer being Rl.SO.IP, - under the subnet 1 0. ,0.0.0, resulting in the 
structure in Figure 8e. 

( ^ Next at Step (7), since we a* not at the last port address, the answeris 
no ; thus processing moves to Step (6), and the port address is set to the next 
address which is shown in Figure 7b at the port address labeled (1) h other 
words, the port address is assigned 10.10A2 with mask 255.255 0 0 

Processing moves back to Step (3), and computes the subnet for the 
port address, which is , 0. 1 0.0.0, and the answer to Step (3) in this case is 
yes because 1 0. 1 0.0.0 matches Conn[2]. 

Processing moves directly to Step (4), rather than going through Step 
(5), and amply adds a pointer to the port address under the matching 
connection (Conn[2]) (i.e., the connection associated with subnet 10 10 0 0) 
Refernng to Figure 8F, there is shown the status at this juncture. 

The process proceeds to Step (7). PA is not the last address So 
processing then goes to Step (6) where PA is assigned the address which is 
shown m Figure 7B at the port address labeled (2). 

Processing moves back to Step (3) and computes the subnet associated 
wrth PA which in this case is 10.20.0.0. The answer to Step (3) is " not in 
SPT", and thus processing moves to Step (5) and adds the subnet to the SPT 
resulting in the structure illustrated in Figure 8g. 

Processing then moves to Step (4) where a pointer is added under 
Conn[3] (i.e., the connection associated with 10.20.0.0) to this port address 
wh.ch is R2,E0,IP1 as shown in Figure 8H. 

Processing moves to Step (7) and since processing has reached the last 
port address the answer is "yes" and the process is terminated. Figure 81 
shows the resulting SPT after all the processing is complete. 

Figure 81 is the SPT for protocol IP. The data structure of Figure 81 
represents the IP connections shown in Figure 5. It „i>I be help*, to see hoW 
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81 corresponds to Figure 5. Referring to the SPT in Figure 81 at the region 
labeled (1), note that there is one subnet (10.30.0.0) that connects to just one 
pointer. A pointer is a link into the SRO substructure corresponding to a port 
address. The single pointer under Conn[i] (in Fig. 81) links to Router Rl's 
port Ea.'s only IP address. Conn[l] can be interpreted as capturing that subnet 
10.30.0.0 which has one router point attached to it, namely router Rl's Ea.. 
Since 'E' refers to an ethernet, this connection can be associated with an 
ethemet. Next, refer to Conn[2] in Figure 81, and note that this is associated 
with subnet 10.10.0.0, which is labeled (3) in Figure 5, the Serial Link. This 
serial link connects two ports, represented in the data structure by the two 
pointers associated with Conn[2], Lastly, Conn(3] corresponds to subnet 
1 0.20.0. 0, which is an ethernet with a single router port attached, Router R2's 
Ea.. 

Figure 8J shows the SPT that would be produced if the procedure in 
Fig. 4 were applied to SROs in FIGs. 7a and 7b for protocol IPX. A difference 
between the IPX and IP walkthrough are that, for IPX, PA will be assigned 
IPX port addresses. Another difference is that for IPX, a SUBNET n , x , rather 
than SUBNETjp would be used in Step 3 of Figure 4. 

It will be apparent from the foregoing discussion that there exist only 
minor distinctions in the process of building the SPT among certain different 
protocols. If the process of Figure 4 was building an AppleTalk SPT, it would 
step through AppleTalk port addresses. Another difference is the function 
"subnet" which is specified in Figure 4 at Step (3) ; For the different protocols 
there are different subnet functions. We described earlier that for IP the port 
addresses which are given by an address and mask - the invention applies the 
mask using "bit-wise AND," and then does the comparison to get the subnet 
from the mask/address combination. For IPX, the condition is much easier. 
The invention simply uses the address specified in the port address which is the 
IPX Network Address. Once again, referring to Figure 7 A, the region labeled 
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(7), note the address is 9C. Next reference Figure 8J and observe that the 
subnet is simply the network number 9C. 

Thus, a significant advantage of the processes and structures of the 
present invention over earlier network management tools is with the present 
invents, one needs go to the live network only once for each router to 
populate the SROs When the SROs are populated, the formation of topology 
» strictly an off-line process that can proceed even if the network at that time 
has re gl on S that are not operational. This is in contrast to other mechanisms 
which uses (on-line) discovery for topology production. 

Another advantage of the invention is in creating topo.ogies for two 
networks that are separate, but areto be merged. Usingthe methodology of 
the present invention, one can obtain the router configurations for one of the 
networks; go to the second network and get the router configurations even 
though they are not connected at this moment; merge them; load the 
configurations into SRO's; make modifications to the configurations to be sure 
the networks interoperate properly; and perform analysis of the new.y merged 
network. Generally, earlier network management tools cannot be used to 
form a topology unless the two networks are merged. 

Figure 9 shows an extension of the SPT Build process shown in Figure 
4. The process in Figure 9 handles a complication where it is possible due to 
m.sconfiguration, that ports on two different routers are given the same 
address. This is a high severity integrity check, a problem that the network 
manager wants to correct on the network without delay. The problem is 
somewhat analogous to a situation where, you are mailing a letter, and two 
people have the exact same address. It is not clear who you Would sent it to 
Dunng the process of forming the topology, a search is made for duplicate 
addres.ee, Figure 9a shows the steps from Figure 4 and inserts the additional 
steps that look for duplicate addresses. 
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Focusing now only on the additional steps add in Figure 9, Step la, is 
inserted between Step (1) and Step (2). Step la sets the duplicate address set 
to empty. The process in Figure 9 will produce not only the SPT, but also an 
integrity check output set that conveys which port addresses refer to the same 

5 address. The comments on the bottom of Figure 9 provide an example of what 
this set might connote. For example, consider the DuplAddrSet (which is a set 
of sets) with elements {PA1, PA3, PA4} means that the port address pointed 
to by PA1, PA3, and PA4 all refer to the exact same address. Similarly, the 
presence of the second set, {PA9, PA7) means that PA9 and PA7 refer to the 

10 same address. As conflicts are identified, the set DuplAddrSet will grow. 

In Step(3 A), if the process finds that the subset of the port address 
being processed is already in the SPT, then it is necessary to determine tf in that 
SPT there are any duplicate addresses. (If the subnet is not in the SPT, it is not 
necessary to do the check since an address equal to PA cannot be in the SPT.) 

1 5 If there aren't any duplicate addresses detected in Step 3(A), the answer will be 
"NO" and we process as normal, going to Step(4) as it appeared in Fig. 4, 
Now, back to Figure 9, Step 3 A; if the test in this step detects an 
address conflict, then processing goes to Step 5. Step 3b is a test that checks 
to see if already, in DuplAddrSet, there exists a member (i.e., a set of port 

20 address pointers) having same address as PA, the current port address)! If the 
answer is Yes, then the matching element is extended to include a pointer to 
PA. If it doesn't, we add a new member to DuplAddrSet containing a pointer 
to PA and a pointer to the port address in SPT exactly matching PA. Thus, 
Steps labeled (la), (3a), (3c), (3b) arid (3d), are added in Figure 9 to look for 

25 duplicate addresses and put them in this duplicate address set, DuplAddrSet. 
Referring to Figure 1, note that the invention forms topology 
information and then determines whether there are any integrity violations (Fig. 
Id and Ig). The address set is the result of one of the integrity checks referred 
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in Figure Id. This is important infomiation that the user can apply in Figure Ih 

to find if there are problems and remove them. 

Figure 10 shows a procedure for calculating another integrity check, 
which is applicable to IP using an SPT. In IP, not only do you want to make 
sure that two addresses do not exactly match, but also you want to be sure that 
address/mask pairs, which intuitively refer to address ranges, either refer to the' 
exact same ranges or do not overlap at all. We don't want the case where they 
overlap. 

Figure 10 illustrates a general procedure for computing the 
"Overlapping Address Range" integrity constraint, which is applicable for 
protocols, such as IP and IPX, that allow interfaces to be configured with 
address ranges. (Note: an IP subnet, as we will see , can be tn&ught of as 
corresponding to an address range). 

the input to the "Overlapping Address Range" flowchart is the SPT for 
the protocol being analyzed, which for our invention can be IP or AppleTalk 
and its output, the set Conflicts, whose elements are the pairs of connections in 
the SPT bemg analyzed that refer to overlapping address ranges. In Step (1) of 
the flowchart (Fig. , 0), the output variable Conflicts is initialized to the empty 
set. In Step (2), the variable Conn is set to the second connection in the SPT. 
(Note: if there is only one connection in the SPT then there cannot be any 
conflicts and we assume this procedure would hot be applied). In Step (3) the 
process looks for any connections in SPT listed before Conn that overlaps with 
* »f any overlap is found, a set containing the two overlapping connections are 
put m as a member of Conflicts; in the bottom of Fig, 10 we show the 
definitions of the Overlap functions, which are the only part of the algorithm 
that Affers from protocol to protocol. In Step (4) the algorithm checks if the 
last connection has been reached; if so, processing terminates; if not processing 
goes to step (5) where Conn is set to the next connection and processing 
repeats for this new connection starting at Step (3). 
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The overlap function for IP (shown in the first box in Fig. 1 0) takes as 
arguments two IP subnets, each which is given by a 32 bit address and 32 bit 
mask. The subnet given by [Al Ml] defines the range of addresses from Al to 
"(Al | -Ml)", where T refers to bitwise OR and "~" to bitwise negation. The 

5 expression "(Al | -Ml) can be thought of producing a 32 bit number formed 
by flipping the bits in Al that were masked out (which are the ones where Ml 
has Is) from Os to Is. The definition for OverlapIP([al ml],[a2 m2]) can be 
interpreted as saying that subnets [al ml] and [a2 m2] overlap if and only if it 
is the case that they are not equal and not disjoint; now two addresses are 

10 disjoint if the lower bound of one of the ranges is greater than the upper bound 
of the other. 

The overlap function for AppleTalk (shown in the second box in Fig. 
10) takes as arguments two Appletalk "subnets", each which is given by a 
lower and upper bound giving a cable range. The definition for 

15 Overlap AppleTalk[[cbrlbl cbrubl], [cbrlb2 cbrub2) can be interpreted as 

saying that the cable ranges [cbrlbl cbrubl] and [cbrlb2 cbrub2) overlap if and 
only if it is the case that they are not equal and not disjoint. 

Remember that we are sequentially moving through overall the 
processes described in Figure 1. We have already talked about the process of 

20 taking text configuration files or MIB data and producing SROs (Fig. la). 
Given the SROs, for each of the protocols that running on the network, 
individual SPTs are formed (part of what is done in Fig. lb). Given each of the 
individual SPTs, there are a number of integrity checks we apply (some of what 
is done in Fig. I'd). For each SPT, duplicate addresses are identified in the 

25 associated protocol. Additionally, for IP, overlapping subnet masks are 
identified. 

Next, we provide examples of the production of views in accordance 
with the process represented in Figure 1c. The first example is illustrated in 
Figure 1 1 . The term "view" as used herein means an abstract representation of 
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a level 3 topology that omits irrelevant elements and logically groups e.ements 
F.gure 1 1 provides a view which groups routers together to show which 
routers and LANs share the same campU se, In Figure 1 1 , we show campuses 
labeled C2, Cl and C3, each containing routers and LANs. Referring to C2 
first, we see that routers R3, R4 and R2 are grouped together appearing in 
Campus C2. Referring to C3 next, we see that router R5 and R6 are grouped 
together and if we look at C 1, We see that there is one router in this ca m pus 
Rl. To understand how this information is captured in data structures in " 
accordance with the invention, refer to Figure ,2. which provides an example 
ofa "View" data structure in instantiated form. The same basic type of data 
structure framework is used for the different type of view, The first element in 
tms V,ew data structure is the atomic attribute "Type" set to "Campus" to 
d-stmguish it from different views, such as the OSPF view. The next attribute 
•Group", „ a list of objects, each of them being what we ca.l a "Group" which 
shows how the routers, link, and LANs, or in our terminology "Connexions" 
tie together. Going back to Figure 12, refer to reference numeral (1) which 
refers to an object with name CI. The next attribute Conn refers to a list of 
pomters to connections in the SPT being abstracted. These connections are the 
hnk Sa ndLAN S th,tbelon g to the group. InFig. ,2, in the group with name 
Gl, we see that the Conn[3], which corresponds to the ethemet 10 20 00 is a 
member. In Figure 11, this ethemet is within the Cl campus group. Groupings 
have two parts, the connections and the router, In Cl of Figure 1 1 note that 
router Rl is i n this grouping. Refer to the Router List attribute at region (6) 
Figure 12 where there is a pointer to just a single router, Rl. 

In Figure 12 reference numeral (2) indicates a pointer into SPT Many 
of the data structures of the present embodiment of the invention are 
mtertwined data structures that connect the topological information to the SRO 
information. 
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Referring to reference numeral (3) in Figure 12, a group corresponding 
to campus C2 is shown, the connection that belongs to it is Conn[l] and the 
routers that belong to it are R2, R3 and R4 (shown at Point (4)). The last 
group (reference number 5), corresponds to campus C3; it has three 
5 connections associated with it, Conn[5], [6], and [7] and two routers, R5 and 
R6. Note that a view might not contain all routers or all connections that are 
contained in an SPT. It merely describes the elements that are relevant to the 
abstraction; In a campus view, some of the connections may be omitted, 
Connections belong to a campus view only if they are LANs. So, for example, 

1 0 Conn[ 1 ] in Figure 1 1 is a FDDI and is in C2. We see that Conn[3 j is an 

Ethernet, and that is in CI; also connections Conn[7], Conn[6] arid Conn[5], 
which are all Ethernets, are in C3. There are two connections, serial links 
(Conn[2] and Conri[4]) in Figure 1 1 that do not appear in Figure 12, because 
serial links do not belong to a particular campus; rather they span campuses. 

15 Figure 13 is a flowchart that illustrates a process for constructing a 

campus View object given as input, an SPT and the SROs that are pointed to 
by the SPT. In Figure 13, we refer to SPT p , where "P" can stand for any 
protocol since basically the same is used for multiple protocols, e ; g., IP, IPX, 
AppleTalk, etc. 

20 Referring to Figure 13, we first initialize the view object (VW) to 

"empty" and set Type to "campus". Next, at step (2), the variable Conn is set 
to the first connection in SPT (really SPT p ). In the following discussion, realize 
that the view object formation process iterates through all the connections in 
the SPT under consideration. 

25 In Step (3), we ask whether the Conn variable is associated with a 

LAN. If the answer is "no", (in other words, Conn is associated with a serial 
link or any other wide area link) then the connection is ignored and processing 
goes to Step (4), which asks whether the last connection in SPT been reached. 
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If it has, the procedure terminates. If it has not, then Conn is set to the next 
connection in the SPT, and processing goes back to Step (3). 

On the other hand, at Step 3, if the Conn is a LAN connection, we go 
to Step (6), which asks whether there is a group in a view already having one 
or more routers in common with those pointed by Conn. (Remember that 
Conn is a connection in a SPT, which has pointers to port addressees, and each 
port address belongs to a router). If the answer is "yes", then we go to Step 
(7) and add to this existing group in the view a pointer to Conn under the Conn 
attribute and pointers to all routers associated with Conn under the Router list 
attribute. If the answer to Step 6 is "no", then processing goes to Step (8) 
where we create a new group. We give each group a unique name, (Campus 
CI, Campus C2, etc.) We add a pointer to Conn connection and to ali routers 
pointed to by this connection. After this step, we go back to Step (4) and find 
out if we reached the last connection. If not, iterate to the next connection. 
Similarly, after Step (7), we go back to Step (4) ask whether we have reached 
the last connection. If not, we continue to process connections until we have 
processed them all. So. the result, upon answering "yes" in Step 4 is that the 
process terminates and the object VW (the view object) will be fully 
instantiated. For example, for the network view in Figure 1 i, we have a view 
20 object like that in Figure 12. 

We will next provide an example involving the formation of an OSPF 
view. OSPF is a particular routing protocol. See, Spohn, Darren L , "Router 
Protocols", Data Network Design, pp. 192-213, McGraw-Hill Inc., 1993. 
Also, see the following Requests for Comment issued by the Internet 
Engineering Task Force (IETF): RFC 1771 - A Border Gateway Protocol 4 
(BGP-4) specification; RFC 1 131 - OSPF specification; and RFC 1058 - 
Routing Information Protocol (RIP). Basically, routers run routing protocols 
in which they exchange and generate information to produce routing tables. 
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For OSPF, a network is grouped into areas with some routers called area 
border router, responsible for exchanging information between areas. 

Figures 14 through 17 deal with creating an exemplary OSPF View. 
Figure 14 gives an intuitive picture of an exemplary OSPF view. Figure 15 
5 shows an example of a data structure that captures the OSPF view of Figure 
14. Figures 1 6a and 16b are portions of the SROs for the routers shown in 
Figure 14 that are relevant for the analysis. Finally, Figure 1 7 is an IP SPt that 
was formed for the routers in Figure 14. 

Referring to 14, there are two Areas, Area 0, (encompassing routers 

10 Rl, R2 and R3) and Area 1, (encompassing routers R6 and R5 and a group 

with a single router 4) which is the area border router between Area 0 and Area 
1; to be more specific, R4 is running both Area 0 and Area 1 . 

Referring to Figure 1 5, there is shown a View data structure that 
captures the grouping of Figure 14 The View object Type is OSPF, The 

1 5 View object's TYPE attribute distinguishes it from other View objects, such as 
the campus view TYPE. Next, note the groups attributes. The group attribute 
comprises a list of group objects. The first group refers to Area 0, the 
connections in that group are, Conn[l], [2], and [3], and the routers in the 
group are, Rl, R2 and R3. The next group refers to Area 1 , which includes 

20 Conn's [4] thru [7] and routers R5 and R6. Finally, there is a group for the 
area border router R4. 

Figures 16a and 16b illustrate how router configurations as captured by 
the SROs contain the information that is used to indicate which areas the 
different routers correspond to. In Figure 16a, we see that the SRO for router 

25 Rl is running an OSPF process, OSPF 1. Note that a router can be running 
many different 0SPF processes. For simplicity here, we only consider cases 
where a router nins just one process. At reference numeral (1), we see that the 
OSPF process on router Rl has an attribute called Net Address, which refers to 
a list of statements indicating what areas the different router interfaces belong 
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to- To find out if an interface belongs to a particular area, you sequentially g0 
down the list of net work statements looking for a match. Referring to Figure 
16a, the process for finding a router interface's area involves first starting at 
network statement object labeled (la) and seeking a match. If there is no 
match, then the process proceeds to the network statement object labe.ed (lb) 
If no match is found in any of the Usfcadda this interface does not belong to 
any Area and is not considered in an OSPF view. 

The actual matching process is as follows. Consider the item lathat 
has 99.30.0.0 and 0.0.255.255 as it matching pattern. Referring to Figure 14 

we see router Rl, port SO has an address of 99.30.20. 1 , which matches 
99.30.0.0 and 0.0.255.255. The second part, 0.0.255.255, is cal.ed an access 
list mask, to distinguish it from the masks found on IP port addresses For 
"port address" mask, the Octet, "255" mean "consider" the corresponding 
address octet during the matching process, and "0" means ignore the 
corresponding address octet. For access lists, the meaning of the matching 
octets are reversed. "255" means ignore the matching address octet and "0" 
means consider it. So for example, the pattern at the network statement (,a) 
means look for addresses that start with 99.30 because there is a corresponding 
0.0 matching octet, but ignore the rest of the address because the mask ends 
w»th 255.255. So we see that Rl,S0 has address 99.30.20. 1 which matches 
•tern la in Figure 1 6a, and consequently R1.S0 belongs to Area 0. Referring to 
Figure 14, R] ,E0 has address is 10.20.35. 1 . This does not match item la but 
does match item lb so this interface (E0 on Rl) is in the specified area Area 0 
In summary, looking at Figure 16, we see that both interfaces, SO and E0 for 
router Rl, shown in Fig. 14 match Area 0. 

As another example of interface matching in OSPF areas, refer to 
reference numeral (2) in Figure 16. Now refer Figure 14 at Router R4 Router 
R4 has two interfaces, Fl whose address is 20.20. 1 0. land SO whose address is 
98.40.10.1. Now going back to Figure 16A, reference numeral (2) shows the 
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network statements for router R4. The first network statement reference 
numeral (2) shows the pattern 98.40 (ignore the rest of the bits). This matches 
Serial O's address (98.40. 10. 1), and thus this interface is in area 1 . However, 
FTs address (20.20.10) does not match the first network statement, (the 

5 statement at reference numeral 2 in Figure 1 6a), but the second network 

statement matches 2b. Thus, Fl (from router R4) is in the area specified by 
network statement 2b, i.e., Area 0. 

For the routers running OSPF, determining what areas their interfaces 
match is an important step in the algorithm for producing the OSPF view. 

10 Very briefly, if there is a router that has one or more interfaces, all of them 
belonging to the same area, then this router will be put in the group for this 
area. For example, you see that routers Rl, R2 and R3, in fig. 14 have all their 
interfaces match a statement associated with area 0. On the other hand, router 
R4 has interfaces that match two different areas, so it is in its own border area 

1 5 group. Similarly, routers R5 and R6, have all their interfaces match area 1 . 
Thus, R5 and R6 are in area 1 . 

An advantage of multiple views is if you have a particular task at hand, 
then a specific view might be particularly suitable. The OSPF view, for 
example, is a view that would be useful for configuring OSPF. In configuring 

20 OSPF, a central concept is specifying what areas each router, running OSPF 

belongs to. So being able in a very succinct way, to observe the area groupings 
is an enormous benefit in gaining a more comprehensive understanding of how 
the OSPF processes are running. 

Placing a router in the wrong area is a very easy mistake to make. For 

25 example, in typing in a configuration, a user's mistyping 1 instead of 0 in a 

single area statement changes what areas a router's interface is in. Thus, it is 
very helpful to have a view based upon OPSF areas to permit easier diagnosis 
of errors, for example. 
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As we mentioned, Figure 1 7 is the IP SPT, which wiJJ be produced by 
running the algorithm we described in Figure 4 on the SROs t0 
routers Rl tpR6 

Figure 1 8 is a flow chart which shows how the OSPF View is produced 
with the inputs being the IP SPT its related SROs. In the course of producing 
the OPSF View, an integrity check is performed which determines whether 
there are two adjacent routers running OSPF that have their connected ports 
asstgned to different areas. This condition is a misconfiguration that should be 
pomted out to a user so he or she can correct the error. In Step (!) of Figure 
1 8, the main object we're bui.ding, the VW object is set to empty with Type set 
to OSPF. In Step (2), the OSPF Conflict set is initialed to empty. I„ this 
algonthm, we will be iterating through the connections in the IP SPT So in 
Step (3) variable Conn is set to the first connection in the IP SPT. Next in 
Step (4), the AreaSet is assigned the set of areas associated with Conn's 
pomters. We wi.l go into detail about this process in Figure 19. If connection 
Conn has one or more ports which are running OSPF, then Conn will be 
processed. On the other hand, if no ports are running OSPF, it is ignored Ifit 
* the case that there is a conflict as, for example, when one port attached to 
Conn has area 1 associated with it, and another port attached to the same Conn 
as area 0 associated with it then AreaSet will hav 6 more than one element So 
let us see how this is done. In Step (5) we ask "how many members are in 
AreaSet »' If the answer is "0" that means that there are no routers touching 
*» connection with ports that run OSPF, and we go to Step (7) meaning that 
we go on to the next connection, ifit exists. At Step (7), the process checks 
whether the last connection has been reached. Ifit has, processing terminates 
Others processing goes to Step (7a) where Conn is set to the next 
connection and the process iterates through the loop again going back through 
(4) to (5), etc. On the other hand, if there is a conflict in which there are two 
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or more areas associated with a single connection, then Conn processing from 
Step (5) goes to Step (6) where the connection Conn is put in OSPF_conflicts. 

Another case arises when the connection is only associated with one 
area in which case the process continues to Step (8). In Step (8), just for 
5 convenience "Area_Ar" refers to the case where there is a single element in 
AreaSet. 

After Step 8, processing proceeds to Step (9) which asks whether the 
area associated with connection Conn is already in the view. If it is in the 
View, then we want to add this connection under this area which is 

10 accomplished at Step (10). On the other hand if the area associated with Conn 
is not in the view, processing goes to Step (11) where a new group labeled 
"Area_Ar" is created and under which there is added a pointer to Conn. From 
both Steps (1 1) and (10), processing goes to Step (12). 

Steps (12) through (17) are responsible for putting routers pointed to 

1 5 by Conn under the appropriate area if they have not already been placed. 

Recall that a connection points to a set of port addresses, each one of them 
corresponds to a router. We set variable PNTR to the first pointer in Conn at 
Step (12). We then go on to (13), which asks whether a router associated with 
this pointer is in the View already". If the answer is yes, then we do not have 

20 to process this router and we go on to Step (16), which asks whether PNTR is 
the last pointer in Conn. In other words, it asks whether we have finished 
processing the routers in Conn. If that is the case, then we go on to Step (7) to 
process the next connection. If not, we go on to (1 8) to process the next 
pointer (more particularly to the router pointed to by this next port address 

25 pointer and go back to Step (13)). 

In Step (13), if the router associated with PNTR has not been 
processed already, we go to Step (14) and ask how many areas the router 
pointed to by PNTR has. Figure 20 shows detail of how the answer to this is 
computed. If the answer is zero, in other words this is a router which is not 
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running OSPF, then we just go on to Step (16). If the area answer is 1, then 
we know that this router is running one area, Area_Ar and thus we put it under 
group Area_Ar under the Router List s attribute. On the other hand, if the 
router is running in more than one area, then we know that it is a border area 
router, and we construct a special group for that router. That happens in Step 
(17) where we create a new group called "Border Area" and a pointer to the 
single router in this group. In the View of Figure 14, router R4 is one of these 
border routers, and hence belongs to its own group. 

Figure 19 is a flow chart which explains details of Step (4) in Figure 18. 
This is a procedure, which given as input a particular Connection in a IP SPT, 
indicates all the areas associated with the router ports which are attached to 
this connection. Let's start at Step (1) in Figure 19. As an overview of the 
following discussion of Figure 1 9, the process for associating areas and router 
ports involves iterating through the pointers contained in the input connection, 
or in other words, iterating over all the routers that are connected to the input' 
connection Conn. At Step (1), PNTR is set to the first pointer in Conn. 

Step (2) asks if a given router pointed to by PNTR has the routing 
process OSPF configured. If the answer is "no" then the procedure does not 
have to process this given router. At Step (3) a determination is made as to 
whether PNTR is the last pointer in Conn. If it is, then processing is finished. 
If not, the process moves to Step (4) in which PNTR is set to the next pointer 
in CONN. The process then returns to Step (2) On the other hand, if the 
given router has OSPF configured, Step (5) is reached. 

Note that for simplicity we assume that a router only has one OSPF 
process, if it has any. The actual implementation of the preferred embodiment, 
however, can handle multiple OSPF protocols on a single router, and this 
process described herein naturally extends to cover that situation. 

At Step (5), for convenience, we let OSPF_obj refer to the OSPF object 
associated with the router pointed to by PNTR. The process then proceeds on 
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to Step (6), which asks whether the OSPF _obj has any network statements. If 
the answer is "no", then the process go back to step (3) and iterates through 
and processes the next router. If the answer is "yes" then "Netstmt" becomes 
the first "network statement" in OSPF_obj. 
5 In steps (7) through (11), the process goes through sequentially the list 

of network of statements associated with the OSPF process to see if the 
address associated with PNTR matches one of those statements. If so, then the 
process uses the area number associated with that network statement. At Step 
(7), the process makes Netstmt the first network statement. Step (8) asks an 

1 0 address associated with PNTR matches the network statement". The details of 
this matching process are described earlier in this specification. If there is a 
match, then the process proceeds to Step 1 1 which adds the area mentioned in 
the network statement to the output AreaSet if it is not there already. 
Processing then goes back to Step (3) to process another router, if any are left. 

15 On the other hand, if at Step (8), the address does not match the network 

statement, then the next OSPF network statement is processed, looking for a 
match, if it exists. 

Figure 20 depicts a flow chart that describes in detail Step (14) in 
Figure 18; it asks how many areas a particular "router" is associated with. We 

20 contrast this with the process in Figure 19 which is the question: how many 
areas a "connection" has associated with it. 

The first step in Figure 20, labeled (0), is to set the output AreaSet to 
empty. The process next goes to Step (1), and asks "whether a router has 
OSPF configured". If the answer is "no", then the process is finished, and the 

25 output area set is empty. If the answer is "yes", the process proceeds to Step 
(2). For convenience the variable OSPF_obj is set to refer to the OSPF object 
associated with the input router. The process then goes to Step (3) which asks 
whether this OSPF object has any network statements. If it does not, then the 
process exits with the answer being that the area set is empty. If it does, the 
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process goes to Step (4) and iterates over the port address on this router. Step 
(4) let s the variable PA be the first IP port address of the input router. The 
process then goes to Step (5). 

Step 5 lets Netstmt be the first network statement in the OSPF object. 
5 Next, Step (6), asks whether PA (the Port address that is currently being 

processed) matches the network statement, Netstmt. This notion of matching 
is the same as that described at Step (8) of Figure 1 9. If there is no match, go- 
to Step (7) and the last network statement has been reached. If the last 
network statement has been reached, go to Step (10) to process the next port 
1 0 address on the router. 

In Step (7), on the other hand, if the last network statement has not yet 
been reached, then go to Step (8), and we set the variable Netstmt to this next 
network statement and iterate through the loop to determine whether there is a 
match. Now referring again to Step (6), if a match is found, then the area 
mentioned in the Netstmt is added to the AreaSet, and the procedure goes to 
(10) to process a new port address. 

The following discussion addresses some of the issues that come up 
with a multi-point WAN, such as Frame Relay. We will first give an intuitive 
description and then show how we modify the flow chart in Figure 4 to account 
for the complications that the multipoint WAN introduces. Let us first start 
with an intuitive view of an exemplary network depicted in Figure 34, which 
shows 4 routers Rl, R2, R3, R4 that are connected through a Frame Relay 
cloud. Each of these routers attach to the Frame Relay cloud through its SO 
port. As far as the Level 3 view is concerned, all the routers that hook into the 
frame relay, such as, Rl and R2 are one hop away. Another consideration to 
note is that all the SO port addresses for all the four routers belong to the same 
subnet, 1 17.33.4.0. If we took the algorithm, described in Fig. 4, (or even 
with the extensions shown in Fig. 9) and just simply applied it to the 
description of this network as given by its SROs, we would produce the SPT 
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depicted in Figure 35. The SPT in Fig. 35 shows that Rl's, R2's, R3*s and R4's 
SO port all are attached to subnet 1 17.33.4.6. The implicit assumption of these 
four ports in the same grouping is that they all could directly reach each other, 
or in network terms, that they are "fully meshed". For a LAN this is the case; 
5 ajl the connected ports can directly communicate. 

A potential problem, however, is that in a multipoint WAN, such as 
Frame Relay for example, the connected routers may not be fully meshed. For 
example in Figure 34 we show that there is only a partial meshing. The dotted 
lines, in the Frame Relay cloud in Figure 34, are there to convey that the pairs 
10 of routers that can directly "talk" are: Rl and R2; Rl and R3; Rl and R4; and 
R2 and R3. This is not a full meshing, for example, because R4 cannot directly 
talk to R3. 

An important aspect of capturing a Level 3 view is capturing the fact 
that R4 and R3 are not directly connected. If we use the SPT in Figure 35, we 

1 5 are not capturing that distinction. Instead, we can use the SPT in Figure 36 to 
represent this incomplete meshing. Figure 36 shows four Connections, all with 
the same subnet 1 1733.4.0. These four Connections show the directly 
connected routers in the Frame Relay Cloud. 

There are a number of sources of information about meshing in a multir 

20 point WAN, such as Frame Relay. One mechanism to determine the meshing is 
by the inclusion in the router configuration text of explicit Frame map 
commands. Looking at Figure 38a at reference numeral (1) there appears 
command, "Frame Relay Map IP", and the address 1 17.33.4,2 and the number 
100 (and the term "broadcast" which is not relevant to the disclosure). This 

25 command which is associated with router Rl's SO port is saying that SO is 

meshed with the address 1 17.33.4.2, an address of R2. So, reference numeral 
(1) in Figure 38a corresponds to the dotted line marked (1) in Figure 34. 
Similarly, referring to the second line under the Frame Relay Command, in 
Figure 38a, we see mention of address 1 17.33.4.3 which corresponds to the 
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dotted line that connects Rl to R3 in Figure 34. Referring next to Figure 38b, 
at reference numeral (3), we see the mapping from Rl to R2 in the other 
direction: from R2 to Rl . In summary, the presence of the map commands in 
router configuration files is one source of information to determine the meshing 
in a Frame Relay cloud, for example. This information often can be obtained 
from text files, such as those shown in exemplary Figures 38a through 38d. 

In Figure 37 there is shown a fragment of the SRO for router Rl that 
focuses on how the Frame Relay maps in Figure 38a translate into the SRO. 
Referring to reference numeral (1 ), note that there is an attribute for port SO, 
which is a list of Frame Relay map objects. In Figure 37, each one of these 
items under Frame Maps labeled (1) which items are labeled (2), (3) and (4), 
correspond to the three Frame Relay Map commands that are present under 
interface SO in Figure 38a. It is a straight-forward translation. Another 
process for determining the meshing in a multi-point WAN is referring to the 
live router and executing a "Show Frame Map" command, parsing the response 
and bringing it in the SRO. 

To handle the complications due to a multi-point WAN we have to 
modify the SPT algorithm that we described in Figure 4. To show how we 
modify this algorithm, we repeat diagram 4, labeling the boxes with letters, 
rather than numbers, which is given in Figure 31. We show the additional 
processing steps, labeled with numbers, that modify it (Figure 32) and then 
we'll just apply the modifications and the show the resulting flowchart (Figure 
33). In Fig. 33, the previous steps are labeled with letters, while the new ones 
are labeled with numbers. 

Referring to the Step labeled (C) in Figure 32, which is the same as 
Step (G) in Figure 31. Step "C" is a test to see if the subnet for the port 
address being processed (PA) is in the SPT. If the case is "no" then we go to 
(D), which is normal processing, and reiterate the process with the next port 
address. On the other hand, if the Subnet (PA) is in the SPT, processing goes 
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to Step (1), which asks whether the port associated with the PA is Frame Relay 
encapsulated. This is determined by looking in the encapsulation attribute of 
the port associated with PA in the SRO. If this is not the case, then normal 
processing takes place and the procedure goes to (E) (again as depicted in 
5 Figure 31). If not, go to the special Frame Relay multi-WAN processing, in 
other words we go to Step (2). In Step (2) the variable FRM is set to the set 
of Frame Relay maps associated with PA's port. The process iterates through 
this set by first setting FRM_ member to the first element of FRM (Step (3)). 
In Step (4) for convenience the variable ConnSet is assigned to the set of 

1 0 connections in SPT that i) match subnet (PA) and ii) have the property that it 
has a pointer exactly matching the address in the variable FRM member. Now 
it's possible this set could be empty. Step (5) asks whether the Conn Set is 
empty. If the answer is yes, then go to Step (10), which asks whether there is a 
connection of SPT matching Subnet (PA) with just a single pointer to PA. If 

1 5 the answer is "no" go to Step (9) and add a new connection with subnet Subnet 
(PA) and with a single pointer to PA. Then go to Step (1 1) to determine if the 
last frame member has been reached. If not, continue in the loop, going to Step 
(12) to set Frm_member to the next element, and continue processing. On the 
other hand, if the answer is "yes" at step (11), then processing of PA is 

20 finished. Then go to Step (F), which is in the original Figure 31, to process the 
next port address. Now, on the other hand if the answer is "yes" at Step (10) 
i.e., there a connection in SPT matching subnet (PA) with just pointer to PA, 
then go to Step (11) and continue in the loop over Frame members. 

Now referring again to Step (5), if ConnSet is not empty then we go to 

25 Step (6), which asks whether there is a member of ConnSet having just one 

pointer. If the answer is "yes", add a pointer to PA to this member, (step (7)), 
and then continue to Step (1 1) to process the remaining elements of FRM, If 
the answer is "no" then go to step (8), and create a new connection whose label 
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is subnet (PA), and under this we add two pointers: one to PA and the other to 
the port address corresponding to the address in FRMmember. 

To give a better fed for the flowchart that we obtained after grafting in 
the add.tional steps to handle multi-point WANs, (Figure 33) we'll walk 
5 through a specific example, the one that's intuitively depicted in Figure 34 

whose configurations appear in Figures 38a through 38d and having an SRO as 
shown in Figure 37. (Figure 37 shows only one of the SROs (for Router Rl)) 
We do not include the SROs for Router R2 through R4 because the process of 
gomg from a config file to a SRO representation for these routers should be 
10 evident. 

Figures 39a through 39f provide a detailed example used as a 
walkthrough of the flow chart depicted in Figure 33. 

Starting at Figure 39a we see reference to Step (1) of the flowchart of 
F.gure 33 where the output, the SPT, is initialized to the structure shown 
opposite Step (1 ). This is an IP SPT. So the protocol is set to IP. m step (2) 
PA is set to the first port address, 1 17.33.41.1 255.255.255.0. At Step (3) the 
question is whether subnet (PA), which is 1 1 7.33.4.0, is i„ the SPT In this 
case it is not because the SPT is empty. Thus, go on to Step (4), which adds a 
new Connection, whose subnet is 1 1 7.33.4.0, to the SPT. Then go to Step (9) 
wh,ch adds a pointer under this subnet to Rl, S0,IP1 (the current port 
address). Referring to Step (9) in Figure 39a, there is shown the structure 
formed by Step (9). After Step (9) go to Step (18), which asks whether PA is 
the last port address. The answer here is "no". Processing goes to Step (19) 

where PA is set to the next port address, 117.33.4.2 255 and 255.255.0. After 
Step (19), go to Step (3), which asks whethe/subnet (PA), (1 1 7.33 4 0) is in 
the SPT. The answer here is "yes" In Figure 39b, there is a continuation of 
the walkthrough continuing from step (3), which answered "yes" Thus the 
current step is Step (5), which asks whether PA is Frame Relay encapsulated 
The answer is "yes". Thus go to Step (6) and set the variable FRM to the set 
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of Frame Relay map addresses associated with PA's port. In this case there are 
two of them, 117.33.4.1 and 117.33.4.3. Then go to Step (7) and set 
FRM_member to the first address, 1 1 7.33.4. 1 . Then go to Step (8) and set the 
variable ConnSet to the connections in the SPT matching subnet 1 17.33.4.0 
5 with a pointer exactly matching the Frame member. In this case, ConnSet 

contains Conn[l] because this has the subnet 1 17.33.4.0 and also has a pointer 
toRl,S0,IPl whose address is 117.33.4.1. 

Next, go to Step (12) which asks whether the Conn_Set is empty. Here 
it has one element and so the answer is "no". Step (15) asks whether there is a 

10 member of ConnSet having just one pointer. The answer here is "yes" because 
Conn [1] only has one pointer. Thus go to Step (16) and add a pointer to PA 
under this connection forming the structure shown at (16) in Figure 39b. Then 
go from Step (16) to Step (10) which asks whether the process has reached the 
last member of FRM. In this case "no" because there is one more element to 

1 5 process. So, the answer at Step (1 0) is "no". 

Refer now to Figure 39c. Since the answer to ( 1 0) was "no", the 
current step is Step (11), and FRMjnember is set to the next element of FRM, 
1 1 7.33.4.3. Then go to Step (8) and set ConnSet to the connections matching 
1 1 7.33.4.0 and also with the pointer exactly matching frame member which is 

20 1 17.33.4.3. In this case there are no connections meeting the second criteria. 
So Step (13) asks whether there is a connection matching subnet (PA) with a 
pointer to PA in SPT? The answer here is "no". Go to Step (14) and add a 
new connection with subnet 1 17.33.4.0 to SPT under it, a pointer to PA. The 
resulting structural addition to the SPT is shown in the diagram at reference 

25 numeral (14) in Figure 39c. Then go to Step (10), which asks if the last 

member of the frame set has been processed. The answer here is "yes," and 
thus we go on to Step (18) which asks whether the last port address has been 
reached. The answer here is "no" because there are more port addresses to 
process. Go to Step (19) which sets the next port address to 1 17.33.4.3 and 
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answers "yes" since ConnSet has a single member. Consequently, processing 
goes to (16) which adds a pointer to PA under this member Conn[2] leading to 
the structure in Figure 39e adjacent to reference numeral (16). After Step (16), 
processing goes to Step (10) which asks if the last FRMjnember in FRM has 
5 been processed. The answer here is "yes". Hence go to Step (18), which asks 
if the last port address has been processed. The answer here is "no". There is 
still one more port address to process. Step (19) sets variable PA to the next 
port address which is 1 17.33.4.4 and 255.255.0. Next, Step (3). At step (3), 
the answer is "yes" since subnet (PA) which equals 1 17.33.4.0, is in the SPT. 
10 We then go to Step (5), which answers "yes" since PA is frame relay 
encapsulated. 

The walkthrough example now continues with Figure 39f. Step (6) sets 
FRM equal to the Frame relay maps. In this case it is a set having one element, 
1 1 7.33,4. 1 . Go to Step (7) where the FRM_member is set to the first element, 

15 which is the only element, 117.33.4.1. In Step (8) look for the connections 

matching subnet 1 17.33.4.0 with a pointer exactly matching FRMjnember. In 
this case two matching elements are found: Conn[l] and Conn[3]. Step (12) 
asks whether the set is empty. The answer here is "no" because it has two 
elements. Go to Step (15), which asks whether there is a member of ConnSet 

20 having just one pointer. The answer here is "no". The two elements both have 
two pointers. Go to Step (17) which adds a new connection with subnet 
1 17.33.4.0 and a pointer to PA, which is R4,S0,IP1, and also to the port 
address corresponding to FRM_member, which is R1,S0,IP1 resulting in the 
SPT structure shown adjacent to reference numeral (17) in Figure 39f. Go to 

25 Step (10) which asks if the last member of FRM has been reached. The answer 
here is "yes". Go to Step (18) which then leads to termination of the procedure 
since the last port address has been processed. 

Next we shall discuss the construction of the MPT, which stands for the 
Multiple Protocol Topology. Referring to Figure lb, the MPT is constructed 
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m Step (4). The MPT is constructed from the set of SPTs. The MPT is as a 
data structure that captures the interrelationships between the different Level 3 
topologies, each of which is encoded as an SPT. A single router's physical 
port can have multiple Level 3 addresses configured on it with different 
protocol, When th,re are m U ,ti p , e addresses from different protocols assigned 
to router's ports in the network there is potential for logical topologies with 
incompatible addresses. 

As used herein, "incompatible addresses" means two level 3 protocols 

An example of a network with incompatible addresses is shown in Figure 26 
wh.ch shows a network with mismatched IP and IPX addresses and two IP and 
IPX connections that would be flagged as being a Mismatch by the process 
shown in Figure 23. The reason that these two connections are in conflict is 
because they overlap by virtue of having the pointer labeled (1) (in Figure 26) 
refer to the same port as the pointer labeled (4) and also having pointers (2) 
and (5) match. On the other hand, pointer (3) does not match pointer (6) and 
thus IP and IPX connections are in conflict. Looking at the network in Figure 
26, we see that this conflict is important to identify because it is caused by mis- 
addressing Router Rl's Tl port with an IP address belonging to subnet 
to. 10. 10.0. The problem could be corrected by instead putting this address on 
Rl's TO port. 

In the process ofbuiUtag a MPT from, S et of SPTs, (one for each 
Level 3 protocol funning on the network), certain existing conflicts DeWee „ 
.he SPTs ea, be identified through certain integrity check, Although networks 
n»y be able to „,„ when their logical topologies have incompatible addresses i, 

" 3 C ° mMOn 10 sre.,1, improves the ability ,„ 

manage the network. Because I, is con™, practice to hw ^ ^ 

be an extremely valuable diagnostic aid that can identity addressing errors As 
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mentioned earlier, it can be important to identify addressing errors because they 
can have substantial impact on network operations. An important benefit of 
computing how logical topologies relate is that information regarding one 
logical topology can be used to fill in missing information about another logical 

5 topology once they are synchronized. We will show, later on, an example of 
how information that would be missed by just looking at the IP topology alone 
because of a Cisco configuration command called IP-unnumbered could be 
filled in by using logical topologies from the other protocols such as IPX and 
AppleTalk. The production of the MPT is a unique aspect of the invention. 

10 The MPT serves to coordinate topologies from different protocols. 

Figure 21 provides an illustration of a MPT data structure, in attribute 
form. A MPT structurally looks very similar to an SPT. A MPT consists of a 
list of objects which are called Multiple Protocol Connections. In Figure 21, 
reference numeral (1) indicates a first multiple protocol connection labeled 

15 MpC[l] . This object contains a list of subnets that it refers to. Each subnet is 
from a different protocol. Note also that, for IPX for example, a network 
number would be included in the list. So, MpC[l ] could have an IP subnet and 
an IPX network number. A multiple protocol connection object also contains a 
list of pointers, not to the port address on a router, but to the port itself. So, a 

20 pointer for a MpC is identified by simply a router and a port. It does not have 
the additional attribute that SPT has which identifies a particular address within 
a port. So one could think of a MPT as tying together router ports and 
grouping them together in the different protocol (sub)nets that correspond to 
each other. 

25 Figure 22 is a flowchart that computes a process which produces a 

MPT from a set of SPTs denoting the different logical topologies. In addition, 
during formation of the MPT the process will also find mismatches between the 
topologies, which are put in a mismatch set which is another output for this 
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process. Identity such wtmMm k , miaiK . chak 
accordance with the invention. 

Note tha. ahhough Figure 22 on|y ^ proceKtos ^ ^ md ^ 
.Hep™ce SslS e 2sily8 e„e raB2 ed tohaKl , e<)therprotorals ^ ^ 
sa m eba S ,cp W esscanbeu SM l t „ processIP , IpXandAppleIall ' 

■"S«p ! ( I ,» nd (i.), tl , etwooutputsoflhe procesMheMpT 

Mismatch se, are initial , 0 ^ ^ fa 
denoted o y S, eps (2) lhrou8h (5) , hMdes , he ,„ md 

"TI - "ively simple pro ces 

«- ^ -Pie, the ,P structure imo llle ^ Slep ^ 

to the first connection in the IP SPT. S.ep(3)addsta„MPTaMpC 
corresponding to this connection. Step (4, lsts whttller „ c „ „ (he 

connection in SPT ff . 'fC» is the , as, ,P connection, uten g „ , 0 Step (6) . , f 
C ,s no. the las, IP Connection, 8 „ ,„ Step (5) Md SM c (o ^ * 
connection a*, repeat the p,oc«s. When Step (6) is reach* the ,p SPT „ as 

been "copied" into the MPT. 

.px sp T Ne ? r p r ss r ~ d by steps <6> ,hr ™ 8h (,2 > 

™ SPT nto the MPT, and also ,„ ok for c0 „ fcts . , n these 
C . used to tterate over *. IPX connection, Step (6) se ts ,o the fa, 
W Connecnon ,„ the IPX SPT, Step R> Mks whelher the result „ f 
Con -on c with the McCs in fc MPT <wh,h a, .his poin, in ,he process 
merely reflect the IP SPT structure.) 

The result of, he ma,ch process is one of four state, One state is a 

■ no match a, al, an, . ta Mle is . ^ 

8 o o S,ep (9, and add ,o the misr„a«ch « *. conflict ^ x .. ,„ d J* 
conn,.™, mernner in MPT. G „ to Step (1 „ , 0 detera ,„ eifc . 
connectton. If it is, the praes s termina.es. 
cordon and 8 o hack to Step (7) . If there „ , ^ ^ 



WO 97/49214 



PCT/US96/10873 



-61- 

then there is an IP connection and an IPX connection that correspond to the 
exact same router ports. In that case, go to Step (8) which adds a new IPX 
subnet to the matching MpC. Then go to Step (1 1), etc. iterating through the 
loop. On the other hand, if there is no match or if there is a subset relationship 
5 in Step (7), then go to Step (10) where a new MpC is created by 14 copying 
over" the IPX connection U C" Next go to Step (11). If C is the last IPX 
Connection, then the process terminates. If not, go to Step (12), and iterate 
through the rest of the IPX connections. 

Figure 23 is a flowchart that provides additional details about Step (7) 

10 in Figure 22. The input for this flowchart is "C", which refers to an IPX 

connection, and the MPT. The process starts at Step (7a) where MPNTR is 
set to the first connection in MPT. Step (7b) asks whether the IPX connection 
intersects the MPNTR. As used herein, the term "intersect" means "refers to 
one or more of the same ports," If the answer is "no", then Step (7h) asks 

1 5 whether MPNTR is the last MpC in the MPT. If the answer is "yes", then all 
the connections in MPT h^ve been processed, and no matches or intersections 
have been found. The process exits with status: completely no match. If there 
are more MPCs to process, then set the variable MPNTR to the next 
connection in MPT (Step 7) and go back to Step (7b). 

20 If at Step (7b), an intersection is found between "C" and MPNTR then 

go to Step (7c) which asks what type of intersection relationship is present. 
Specifically, the question is whether there is a one to one correspondence 
between MPNTR and "C" That is, do they point to the exact same router 
ports? If the answer is "yes" then the process exits with status: a complete 

25 match. If there is not a one-to-one correspondence, then Step (7e) asks 

whether the ports in "C" refer to a proper subset of the ports referred to by 
MPNTR or visa versa. In other words, do we have a subset relationship? If 
the answer is "yes" then the procedure exists with status: subset relationship. 
If not, the process exits with a mismatch status. 
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figure, 24a through 24i, illume a watahrough example of the 
flowcharts of Figure, 22 and a Jhe wa]kthroi]gh ^ ^ 

Ftgures 24a through 24, uses as input the ,P SPT in Figure „ Md ^ $pT 
- F-gure „. Recall tha, SPTs were produced ftom the SROs in 
Figures 7a and 7b. The SROs, in , U m represent ,he router configu^, ffles 
s own ,„ Fialres 6a ^ & M ^ pjg ufe 5 , inlMded « 

fcstrauorrofthe routers in the network. 

R ^™ 8 '0Rgure24 M hed i .gran,show S ,hes,a,eof,he„ u , put 
after Step (I) in Figure 22 is ^ ^ ^ 

.nd.ca.es tha, a, Step „a) in Figure 22, MisMatch is ^ to erapty 
Step P) sets X" to the firs, .P connection in SPT ,P, Co„„[„ i„ Figure 8i 

^T. F ,g„re 24h shows the resulting MPT state after applyi „ g ^ <3) , 
Note the sumlarity between the structure in figure 24o and the suture 
-W I ,s („ in Figure 8i . a, differenM is ^ ^ 

2^*2.^. ^^^^ ■ 

address on a port, a connection in , MPT just points to the port itseif 

^ figures 24. and 24b show the main operation in processing the IP SPT 

.hepo.ntersintheffSPTarecopiedintotheMPT.orni.t.gtheiraddress ' 
references yielding p„i„ t ers ju!I menlion i„ g , ^ ^ , 

P0.n.,„g ,„ a higher levei in ,h. SRO structure and being independent of 

protocol. 

_ Figure 24c shows the results after processing the ne« connection 
wh,ch ts Conn-2, (See Figuro Si) . The diagram in Figure 24c shows the state 
o^^TafterS,ep ( 3>i s _ W ,heseco D d,ime.Onceag,„,„ 0 ir 
a™ amy hetween the stature in Fig „re 24c and the firs, two connections in 
the structure of Figure 8i. 

s ^J i gure24d,n„s m ,es.hes,a.e„f,heMPTaft,rCo„n f 3 ] isprocessedi„ 
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Figure 24e shows the state of the MPT after the last IP SPT has been 
processed. 

We have now discussed the first part of the process in Figure 22, where 
the IP SPT is copied over to the MPT. Next, the process iterates through the 
5 IPX SPT where an additional step is performed that looks for matches and 
mismatches. Figure 24f continues the walkthrough example at Step (6). In 
this part of the flowchart, the variable "C" is set to the connections in the SPT 
IPX. In Step (6), "C" is set to Corinp] in Figure 8j which has (sub)net 9C. 
Step (7) determines the type of matching relationship between "C" and the 

10 MPT in Figure 24e. In this case, the result is a complete match. The reason 

that there is a complete match between the connection in Figure 8j (with subnet 
9C) and the first connection in the MPT is that ihey both corresponded to only 
one router port, Rl, E0. As a result, since the answer to Step (7) is a complete 
match, go to Step (8) which "adds C's subnet to the matching MpC. The 

15 subnet corresponding to "C" is 9C. Referring to Figure 24f there is shown 
subnet: 9C" which has been added under MpC[l]. 

Referring to Figure 24g, Step (11) asks, whether "C" is the last IPX 
connection. The answer is "no" because there are two more IPX connections 
to process. Step (12) sets G to the next IPX connection, Conn[2] as shown in 

20 Figure 8j, which has subnet 7 A. Step (7) then asks what is the result of 

matching this IPX connection with the MPT. In this case, it is found to be an 
exact match with MpC[2J. Now, refer back to Figure 24f, which is the state of 
the MPT at the time the matching takes place. The reason that it is an exact 
match is that MpC [2] it refers to two router parts, Rl SO and R2 SO and so 

25 does Conn[2j in Figure 8j. Because there is an exact match, go to Step (8) and 
add "C's" subnet (7 A) under MpC[2] yielding the structure in Figure 24g. 
Then go to Step (1 1) which asks whether "C" is the last IPX connection. The 
answer is "no" because there is one more IPX Connection to process. 
Step (12) "C" is to the next IPX connection, which in Figure 8j is Conn[3], 
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which has subnet 98. Then go to Step (7) which once again finds an exact 
match. Note that in Figure 8j Conn[3] has a pointer to one router port R2 EO 
as does MpC[3] as shown in Figure 24, Because there is an exact match go 
to Step (8) which adds "CV (Sub) net 98 under M P C[3] yielding the structure 
shown in Figure 24h. Finally, Step (1 1) determines that the last IPX 
connection has been reached, and the process exists. The resulting competed 
MPT is the structure shown in Figure 24i. 

Figure 25 shows the integration of the example MPT with the example 
SROs. When we presented the MPTs earlier there were just pointers, here we 
replace pointers with the actual SROs to better illustrate the integrated 
structure. This is a novel aspect of the invention, the fact that the object 
model does not merely manage isolated routers, but rather maintain the 
interrelationships among routers. Specifically, the MPTs and the SPTs 
interrelate the SROs. 

Note that in Figure 25 there are two type of links connoting two 
Afferent relationships, the single links represent a component relationship (for 
example, the object type MPT has MPC components). The double lines 
represent pointers. A pointer differs from a component-link in that it links to a 

separate object. 

As mentioned above, one of the advantages of forming a MPT is that 
information from one logical protocol can be used to fill in missing information 
from another logical protocol. The following figures show how information 
that „ omitted from the IP SPT could be filled in from another protoco. such 
as IPX. Qsco Systems, for example, has a configuration option called IP- 
unnumbered, where on a particular router port, rather than explicitly giving it 
an IP address, the IP-unnumbered command could be used. One advantage of 
th.s configuration option is that it helps to conserve the address space 
However, a problematic ramification of using IP-unnumbered is that since a 
port configured with IP-unnumbered does not have its own address it cannot 
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be readily matched up to the other router ports. Remember that in Figure 4, 
which shows how to produce the SPTs, a critical aspect of the SPT formation 
process is knowing the port addresses and matching them up. So, if a port 
lacks a port address, the process, in a sense, is blocked. The example network 
5 of Figure 28 shall be used to illustrate; a procedure that accommodates IP- 
unnumbered. The example network with four routers, R3, R4, R5 and R6. 
Router R3 and Router R4 are connected through their FDDI 1 interfaces to a 
FDDI ring whose subnet is 20.20.0.0. Router R3 and Router R5 are connected 
through their Serial 0 interfaces to a serial link, which is explicitly assigned an 

10 IPX network number, but no IP address (because IP-unnumbered is being 

used) Routers R4 and R6 are connected through their serial 0 interfaces with 
a serial link that is given an IPX network number (9C) but no IP address. Now 
look at the configuration files for these four routers and what their SRQs 
structures. In Figures 29a through 29d we show the four configuration files. 

1 5 Refer to Figure 29a reference numeral (1). Under interface Serial 0, rather than 
explicitly having an IP address with an address and mask, we see the IP- 
unnumbered command. (Note: The interface mentioned in the command, 
loopback 1, will not be further discussed because it is not relevant to the 
present discussion. However, to give a little more background or what a 

20 loopback is: while a router has a number of physical interfaces such as serial, 
FDDI and Ethernet interfaces, the user can manually configure as many 
loopback interfaces as he or she wants. These serve, in a sense, as a way of 
addressing a router, if a host wants to reach a router, it needs to mention an 
address on the router's ports. A common technique is to supply loopbacks to 

25 serve as addresses into a router; an advantage of a loopback address over the 
address of a physical port, is that a "loopback cannot fail"), 

Figures 29b through 29d each have IP-unnumbered configurations on 
their respective Serial 0 interfaces. Figures 30a through 30d show the SROs 
that are produced by parsing and filling in the defaults of the configuration files 
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that are shown in Figures 29a through 29d. Figure 30a shows the SRO 
corresponding to Figure 29a. It's a straightforward translation. The only thing 
to highlight here is the protocol address indicated by numeral (1). Rather than 
including an address, an object type, "Unnumbered" is provided. The structure 
in Figure 30a indicates that the router is an IP-unnumbered and points to the 
loopback LI . Similarly, Figure 30b corresponds to Figure 29b, Figure 30c 
corresponds to Figure 29c and Figure 30d corresponds to Figure 29d. 

Figure 27 shows a flow chart that takes as input the MPT and the SROs 
it points to, and as a result of processing will add more items to the MPT to fill 
in the missing information that's missing in the IP SPT due to the use of IP- 
unnumbered. 

Figure 30e shows the IP and IPX SPTs that would be produced for the 
network intuitively shown in Figure 28 and with routers having the 
configuration files shown in Figures 29a - 29d. Notice that the IP SPT only has 
a connection for the FDDI because only at the FDDI ports are there are explicit 
IP port addresses. At all the serial ports, IP-unnumbered is used. The IPX SPT, 
on the other hand, has connections associated with the two serial links. 

In Figure 27, Step (1) sets C to the first connection in MPT. Step (2) 
asks whether this connection has a non-IP subnet. If the answer is "no", then 
this Connection does not need to be processed, and the process goes to Step 
(3) to process the next connection in the MPT. If at step (2), the answer is 
"yes", then go to Step (5) and determine whether C has all the pointers 
associated with ports that have IP-unnumbered address If the answer is "no", 
then continue at step (3) and process the next connection in the MPT. If the 
25 answer is "yes", then add to connection IP a new subnet labeled "IP- 
unnumbered." 

Figure 30f shows the MPT that would be produced after performing the 
MPT construction algorithm, shown in Figure 22, and then applying the 
algorithm for handling missing information due to IP unnumbered, shown in 
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Figure 27. Before the IP-unnumbered processing takes place, the MPT would 
look like Figure 3 Of with the exception that connection MPC[1] would only 
have a single subnet 9c, and not "IP-unnumbered" in the subnet list; similarly 
MPC[2] would only have a single subnet 8b, and not "IP-unnumbered" in the 
5 subnet list. The IP-unnumbered subnets shown at points (1) and (2) in Figure 
30f are added during execution of the "IP unnumbered processing algorithm 
(Figure 27). The reason that "subnet: IP-unnumbered H is added under MPC[1] 
is the presence of the IPX connection between ports R3,S0 and R5,S0 and the 
fact that both of these ports are configured for IP-unnumbered. Similarly, the 

10 reason that "subnet: IP- unnumbered" is added under MPC[s]is the presence of 
the IPX connection between ports R4,S0 and R6,S0 and the fact that both of 
these ports are configured for IP-unnumbered. 

Figure 40 is a flow chart that describes the process for finding 
mismatched bandwidth statements and mismatched delay statements. (Note: 

1 5 this is a non-routing integrity check; see Figure Id). On each port in a router, a 
bandwidth and delay statement is either explicitly or implicitly configured. 
These are used by both the IGRP and EIGRP routing protocols to compute the 
"cost" of a routing path. The process illustrated by flowchart in Figure 40 
looks for conflicts, where two adjacent router ports are configured with 

20 different bandwidth and/or delay metrics, which may or may not be a problem. 
Because mismatching may be inadvertent and detrimental to the network 
operation, it is valuable integrity check information to present to the user. 

The input of this procedure is the SPT^ and the SRO's that it points 
to. The output is a violation set which is initialized to empty in Step (1). In 

25 Step (2), the variable C is set to the first connection in the SPT^. The process 
iterates through all the connections in the SPV Step (3), asks whether there 
are two or more pointers in C (recall these are pointers to port addresses) 
associated with ports having bandwidth or delay that are unequal. If the 
answer is "yes", go to Step (4) and add the ports in C with a conflicting 
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bandwidth or delay to the violation set. Then go to Step (5), which asks 
whether C is the last connection. If it is, t he procedure terminates. If not, go 
back to Step (3). If in Step (3) the answer is "no conflict", go to Step (5\ and 
process the next connection in the SPIV 

Figure 41 provides a flow chart depicting process for performing 
another type of non-routing integrity check, (Figure 2) which looks for static 
routes configured on the router that point to routers that do not exist in the 
network being analyzed. This may or may not be a problem. It is a problem in 
the case that the static route's next hop address is incorrectly specified; in 
which case, it will not match an existing router. On the other hand it might 
point to a router outside the domain being analyzed; in which case, the user 
could discount the integrity check. Let us go step by step through the flow 
chart. The input to this flow chart is the set of SROs spanning the network. 
The output is a violation list which in Step (1) is initialized to "empty". The 
process steps through all the routers and all the static routes configured. Step 
(2) sets ST to the first static route in the list of routers. Step (3) asks whether 
there is a router with an IP port address that matches the static route's next 
hop address. To determine this, the procedure searches through all the SROs. 
If no match is found, then add to the violation list, a pointer to this static route 
object, meaning that this static route refers to a next-hop router that is not in 
the domain of analysis. Step (5) asks whether ST is the last static route in the 
list of routers. If the answer is "yes", the process terminates. If the answer is 
"no", ST is set to the next static route and process repeats. If the answer to 
Step (3) is "yes", then the address in the static route is within the set of routers, 
and the procedure goes to Step (5) to process the next static route if it exists. 

Figure 43 describes another non-routing table integrity check (See 
Figure Id.) This integrity check is responsible for looking at all the routers' 
access lists to find problems within an access list. An access list is a set of 
patterns used to filter traffic going into and out of a router. Given a destination 
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to filter, an access-list will be processed starting at its first element. If the 
destination matches this first element, then the router looks at the action 
associated with the element; if it's a "permit", the destination gets through; if 
it's a "deny", the destination is filtered. If the first element does not match, the 
router goes on to the next element and looks for a match. If processing gets to 
the end of the access list (and thus there's no match) the destination is filtered. 
The checks that are depicted in Figure 43 look at an access list to see if there 
are two or more elements in the access list where the earlier one is more 
general than the later one. If that is the case, the latter one will never be 
reached. This relation is called a "subsumption relation". The high severity 
error occurs when the two access elements in the subsumption relation have 
different actions: one says "permit" and the other says "deny". The less severe 
integrity check occurs when the access list elements in the subsumption relation 
refer to the same action. In this latter case, it's an issue of efficiency, in the 
first case, it's probably a problem, where the user didn't realize that processing 
would not reach this more specific entry later in the list. 

Figure 43 illustrates how the process finds subsumption problems in the 
access lists of the routers. The input to this flow chart is the list of SROs and 
the output is a violation list which has the access list element pairs that are in 
violation. Step 1 of Figure 43 sets the violation list to "empty". Step (2) sets 
R to the first SRO, that is, to the first router in the list of routers. Step (3) asks 
whether R has one or more access lists. If the answer is "no", then there is no 
need to process this router and the process moves to Step (4) which asks 
whether the last router has been reached. If so, the process terminates. If not, 
Step (5) is reached which sets R to the next SRO and then continues at 
Step (3). If in Step (3), router (R) has an access list, then set a variable Acc to 
the first access list in R at Step (6). 

(A router can have one or many access lists.) Step (7) asks whether the access 
list has more than one element. If it only has one element, then there's no 
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processing to do because the algorithm is looking for conflicts between two 
elements. So if the answer is «„ 0 ", move to Step (8), which asks whether Acc 
■S the last access list in R. If the answer is "yes", then go to Step (4) and 
process the next routen If the answeris "no", then set the variable Acctothe 
next access list in router (R) and then process this access list. If the answer to 
Step (7) is "ye,', that is, the access list pointed to by Acc has more than one 
element, then in Step (1 0) set AcEL, which will be a pointer to an access 
element, to the second element in Acc. Step (, 1) asks whether there is any 
element in the access list Acc before AcEL which is equal to or more general 
than AcEL. If this is the case, then conflicts have been located Goto 
Step (12) where these conflicts are placed in the violation list. If this is not the 
case then at Step (13), ask whether the last element in ACC has been Cached 
If the last element in Acc has been reached, then move on to Step (8) which 
processes the next access list in Router R (if i, exists). If the answer is "no" at 
Step (13), then Step (14) sets AcEL to the next dement in the access .i st and 
the process continues processing this access-list element. 

Each router typically has a routing table for each Level 3 protocol A 
routmg table is responsible for determining the "next hop" a packet of data 
must take along the way from its source to its destination. The "next hop- 
refers to the next adjacent router along the "path" through the network that the 
packet(s) will take en route to its ultimate destination. A routing table consists 
of a set of elements, each having a destination to match against and a "next 
hop" specification. When a packet enters a router, the router looks in itS 
routmg table to find a matching element If a match is found, then this element 
■nd.cates the next hop (Note: there could be more than one next hop, meaning 
that there are multiple choices). It is possible that for a particular destination 
no route is not in the routing table. If that is the case, the router ,ooks for what 
.s called a gateway of last resort which might or might not be set . If it is not 
set, then packet being matched is dropped by the router. If a gateway of last 



-71- 

resort is set, it will be handled like any other routing table element, which the 
router will use as a defined "next hop". 

Figure 45 shows, in attribute form, a Routing Table Object. For each 
Level 3 protocol, each router will have a Routing Table Object. In the first 
field of the Routing Table Object is the Protocol attribute, which is set to IP, 
IPX, APPLETALK, etc. In the second field is a pointer which is either empty 
or references a gateway of last resort (which is a Routing Table Element 
object described below). The last high-level attribute, which contains the bulk 
of this object, is a set of routing table elements. Each one of these mentions a 
destination and if this destination matches, where to go next. 

In Figure 45, reference numeral (1) refers to routing table element 
EL[I], which includes a destination. The different protocols have different 
ways of describing the destination. For IP, a destination is given by an address 
and a mask. For example, consider a destination with an address being 
10. 10.0.0 and a mask being 255.255.0.0. In this context 255 in the mask 
means pay attention to the corresponding octet, 0 means ignore the 
corresponding octet. So for example, 10.10.0.0 255.255.0.0 would match 
anything that starts with 10. 10 and any other setting of the last two octets. In 
general mask Octets can be any number from 0 to 255 and "matching" is 
decided by applying the mask using Bit-wise AND. 

The second part of a routing table is an attribute "Cost Paths", which 
can have one or more elements. Each Cost Path element (see reference 
numeral (2) in Figure 45) contains five attributes. First, is Protocol indicating 
the routing protocol that caused the element to be put in the routing table. 
This attribute can have a number of settings. A routing table element could be 
there because it is a directly connected interface; it could be there because there 
was a static route; or it could be there because it was learned by a dynamic 
routing protocol such as RIP, IGRP or OSPF, etc. The second field, 
Cost/Administrative distance, is an attribute that is used in the case of two or 
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more routes being available. When there are two routes, the router tries to 
determine the best route. The Cost/Admin, distance valve is a metric that is 
used for comparison to find the best route. The third field, Interface, tells 
which port/interface to send a matching packet out of. The Next Hop pointer 
will be non-empty if the protocol was learned either from a static route or a 
dynamic protocol and this tells what next router to send the packet to. Lastly, 
the field, Interface Conn, refers to a connection in the SPT of the 
corresponding protocol that is attached to the interface identified in the third 
field. 

Recall that cost-paths may have one or more elements. It is possible to 
have a number of equal cost-paths in which case cost-paths will have two or 
more elements showing the different ways the router can route the packet. 

The routing table data structures can be obtained in two basic ways; 
these structures can be obtained by reading the routing tables from the live 
1 5 routers in the network (the process shown in Fig le) or by computing them, 
through simulation, using the integrated SPT/SRO object model as input (the 
process shown in Fig If). If IP routing tables are being computed then the IP 
SPT is used; if IPX routing tables are being computed then the IPX SPT is 
used, etc. 

An important benefit of computing routing tables, rather than observing 
them, is that a simulation using computed routing tables can indicate what 
happens to the routers under hypothetical failure scenarios enabling a pro- 
active failure analysis. 

The routing tables being used and computed by the invention refer to 
25 "steady-state" routing tables. The steady-state routing tables are the routing 

tables that are produced once the routing process settles; in a live network, the 
routing tables can converge to a new state when network devices or router 
ports change in status (i.e., whether they are operational or failed); routing 
tables can also converge to a new state when the configuration of the routers or 
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other network devices are changed, new devices are added, or existing ones 
removed. By saying that the invention is computing steady-state routing tables, 
we mean to imply that the invention is not computing information about the 
convergence process, such as the settling time or the number of messages 
5 exchanged during convergence. 

Focusing on steady-state, rather than also the transient states, allows 
novel efficient techniques to be applied in this invention because the invention 
can "cut to the chase"; this is in contrast to the live routers running, for 
example, the periodic distance vector protocols, such as RIP and IGRP, which 
10 must do a lot more cycling before obtaining a steady-state. 

The invention's routing table simulation technique draws on the 
published specification of the standardized routing algorithms, such as RIP and 
OSPF, and draws on the vendors' public specification of their own proprietary 
routing protocols, such as Cisco's IGRP and EIGRP routing protocols, as well 
1 5 as the vendors embellishments and slight modifications to the standardized 
routing protocols. 

We separate the part of the invention that models the published 
algorithms from the rest of the structure, which constitutes the invention's 
novel contribution, by defining the functions below, which capture the 
20 published algorithm's behavior. These functions below are used for all of the 
routing protocols being treated. 

SEND(RT_EL,RP <Ro,Po>) is a function computable from Ro's SRO 
that returns either null if router Ro cannot generate from routing table element 
RT JEL an update using routing protocol RP and send it out interface Po; 
25 otherwise this function returns the routing table element that router Ro would 
send when advertising route RTEl out interface Po using protocol RP. If 
SEND(RTJEL,RP,<Ro,Po>) is non-null, then its destination is either the same 
as RT_EL's destination or more general than RTEL's destination (in which 
case we say that it refers to a summarized route). Also, if the value of 
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SEND(RT_EL ) RP ) <Ro,Po>) is non-null, then the protocol attribute associated 
this value will be RP. If the element RT_EL has its protocol attribute set to RP 
or to Direct Connect (meaning that it refers to a directly connected interface) 
then we say that SEND(RT_EL,RP,<R 0) P 0 >) refers to natively sending 
RT_EL; otherwise we say that SEND(RTJEL,RP,<Ro,Po>) refers to 
redistribution of RT_EL into protocol RP. 

The function SEND(RT_EL ) RP > <R 0)Po >) embodies the routing update 
"sending" behavior enabled by the configuration of protocol RP for router R 0> 
which is captured by the (routing) protocol object in Ro's SRO with Protocol 
attribute set to RP (see Fig, 2 for the placement of this object in the SRO and a 
partial view of a routing protocol object). There are many routing protocol 
configuration commands that impact what routes can be sent out; for example, 
route filters can be configured for a routing protocol, which consist of 
references to access-lists that indicate which destinations a routing protocol can 
send out. Another example is passive interfaces; if protocol RP has a passive 
interface on interface (i.e., port) Po, then this protocol will not send any 
updates out of port Po. 

RECEIVE(RT_EL,RP,<Ro,Po>) is a function computable from Ro's 
SRO that returns null if either router Ro is not running protocol RP or Ro will 
filter or otherwise block element RTEL in an update from routing protocol 
RP coming in interface Po; otherwise the function returns the routing table 
element that router Ro will consider putting in its routing table when receiving 
an update from RP containing element RT EL. 

Suppose that RECEIVE(RT_EL,RP ) <R 0 ,P 0 >) is non-null and returns 
RT_EL2; in this case RT_EL and RT_EL2 can differ in the following ways: i) 
RT_EL2's and RT_EL's costlnfo object's cost/admin, dist attributes typically 
will differ (with RT_EL2's cost/admin, dist typically being larger), ii) RT_EL2's 
Interface attribute will be set to the name associated with Po, iii) RT_EL2's 
Interface_Conn attribute will be set to the SPT connection attached to Po, and 
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iv) Next_hop ^pointer will be set to the pointer on the SPT connection 
associating with the router sending the update (so being more formal would 
require RECEIVE to take as another argument the sending router) 

The function RECEIVE(RTJEL,RP,<Ro,Po>) embodies the routing 
5 update "receiving" behavior enabled by the configuration of protocol RP on 
router Rp (if RP happens to be enabled on Ro). For example, a configuration 
option that can block the reception of incoming updates is the setting of an 
input route filter. 

COMPARE(CostInfol,Costlnfo2,RP,Ro) - is a function computable 

10 from Ro's SRO that returns one of the three states: Greater_than, Equal_to, or 
Less_than. If cost/admin, distance of Costlnfol is less than that of CostInfo2, 
Less_than is returned; if the cost/admin, distance of Costlnfol is greater than 
that of CostInfo2, Greater_than is returned; otherwise the two cost/admin, 
distances are equal and Equal is returned. 

1 5 (Note: For simplicity here we are not presenting the more general form 

of SEND and RECEIVE used in the invention that is applicable in cases where 
the router sending the update and the one directly receiving it are not directly 
connected, such as can be the case for BGP (which can use remote neighbors). 
The invention generalizes SEND and RECEIVE so that, rather than just taking 

20 a port as an input, it can also take an argument that designates the router that is 
receiving or sending the update) 

Figure 44 depicts the process the invention uses to compute the steady- 
state routing tables for protocol P (e.g„ IP, IPX, AppleTalk) given a SPT for 
protocol P, the SROs it points to, and the operational status of each router, 

25 each of its ports, and each of the connections in the SPT. A routing table is 

computed for each router in the set of SROs given as input. The output routing 
tables are the steady state routing tables that would be produced by running all 
the routing protocols that are specified in each router's SRO. The invention's 
algorithm is applicable when there are multiple routing protocols running on 
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one or more routers. It also handles redistribution between routing protocols; 
that is, for example, router RI might learn about a destination through RIP and 
if it is configured to do so can re-advertise this route by IGRP if redistribution 
from RTF into IGRP is enabled. Lastly, the algorithm handles summarization as 
embodied by the SEND function, which has the property that it returns an 
output routing table element that can have a more generalized routing table 
element destination than the input element (to capture summarization cases). 

A novel aspect of the invention is that all routing protocols are 
simulated using a distance vector message passing scheme based on 
incremental updates, similar as to what is used by EIGRP. This scheme 
produces the steady-state routing tables that are produced by routing 
algorithms that use difference methods during their convergence process, such 
as periodic distance vector (RIP and IGRP), link state (OSPF, IS-IS, and 
NLSP), and BGP. Also, for IP destinations for all the protocols take both a 32 
bit address and 32 bit mask, rather than just a 32 bit destination used by RIP 
and IGRP. This treatment provides, although, more general than needed for 
RIP and IGRP are for uniformity in implementation across routing protocols. 
The advantage of treating all these type of routing algorithms with one type of 
scheme is that it facilitates a general mechanism for explanation and it makes 
incorporating a new routing algorithm into the invention much easier to handle. 

In Step (1) of the "routing table simulation algorithm" (shown in Fig 
44), each routing table (for protocol P) for each router is initialized to empty. 
In Step (2), for each operational router Ro, routes (i.e., Routing Table Element 
objects) corresponding to Ro's port addresses (for protocol P) on ports that 
have operational status are put into Ro's routing table with Protocol set to 
Direct Connect (see Fig: 45, point 2); also each static route configured on Ro 
(see point 5 on Figure 2) that is not associated with a failed port, is put in Ro's 
routing table with Protocol set to Static_to_next_hop (note: there are two 
types of static routes; static routes which mention a next hop address and static 
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routes that mention a router interface; although the invention treats both types, 
for simplicity in the Patent we just discuss the statics to a next hop address). 

In Step (3) the static and directly connected routes are advertised. For 
each operational router Ro, each of its routing protocols RP will try to 
5 advertise update messages out its operational ports for the static and directly 
connected routes put in its routing table (in Step (2). The function SEND is 
used in this step to determine which routes are permitted to be advertised out 
of what ports (as dictated by each router's configuration as captured by its SRO 
(from which SEND is computable)). 

10 An update message sent from Router Ro out port Po in Step (3) is 

directed (in the simulation) to the SPT connection that is attached to (i.e., 
points to) router Ro's port Po. In Step (4), each failed connection drops any 
message it receives, while each operational connection passes the message to 
each of the other Router/ports attached to the connection. 

1 5 Step (5) refers to the process where for each update that an operational 

router receives, it determines for each routing table element in the update 
whether it should be processed or discarded. A failed router that receives an 
update or a router that receives an update through a failed port simply drops 
the update. The RECEIVE function is used in Step (5) to determine if a router 

20 is configured to receive each routing table element in an update message. In 
Step (5), the router is also computing the new cost/admin, distance to be used 
for a received element, which is typically higher than the one it received (this 
"new cost" computation is embodied in the RECEIVE function); in Step (5) the 
router also discards any element where its new cost/admin, distance is greater 

25 than an routing table element already in the routing table with matching 
destination. The function COMPARE is used in this step to make this 
cost/admin, distance comparison. The output of Step (5) is a set of 
UPDTOPROC sets for each router, capturing the update elements that need 
further processing. 
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In Step (6), for each router Ro with one or more UPD_TO_PROC sets, 
it will add each member from each one of these sets and put it in its routing 
table, replacing any route previously in its routing table having higher 
cost/admin, distance. If the new route being added matches a route already in 
the table with equal cost/admin, distance, then the resulting table will have 
multiple (equal cost routes). Another condition mentioned in Step (5) is not an 
"exact match"; by this we mean that two routes have exact same destinations, 
cost/admin distances and in addition match on the other attributes, such as 
Interface (see Figure 45 point 1). (Note: for simplicity here we just present an 
algorithm that allows multiple routes that have equal cost/admin, distance; this 
is easily generalized to handle multiple routes where the costs may differ, a 
possibility for example, when using Cisco's IGRP variance command). 

In Step (7) each UPD_TO_PROC set is examined to look for and 
remove any routing table element that when put in is an "equal cost/admin, 
distance" route, that is a route that matched an existing destination and has 
equal cost/admin, distance. The reason for removing these elements is because 
in the next step these "incremental changes" will be sent out and it is not 
necessary to send out an incremental change corresponding to a new, but equal 
cost/admin, distance route. 

In Step (8), the "incremental updates", which are in the UP_TO_PROC 
sets will be advertised both through the native protocol associated with each 
element in a UPD_TO_PROC set and by redistribution. The SEND function is 
used in this step to determine which advertisements and redistributions are 
permitted by the configuration. Consider an element EL in a UPD_TO_PROC 
25 set for router Ro. For the protocol RP associated with EL, 

SEND(EL s RP,Ro,Po) will be non-null only if the router Ro is configured to 
natively send EL (using protocol RP) out Po. For a routing protocol RP X 
different from El's protocol, SEND(EL,RP_X,Ro,Po) will be non-null only if 
the router Ro is configured to redistribute from EL's protocol to RP^_X and 
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send it out port Po. Like Step (3), Step (8) will only send updates out 
operational ports. 

Step (9) checks whether any updates are sent in Step (8); if not then the 
process terminates; otherwise the algorithm loops back to Step (4) where the 
5 new updates are processed. 

Figures 44a and 44b show grafts onto the algorithm in Fig 44 for 
additional processing that efficiently handles loop conditions; as an update is 
passed from router to router, the update is tagged to produce the list of routers 
that the update has visited. The tagging is done in Step (A) shown in figure 

1 0 44a, which is inserted between Fig 44's Steps (3) and (4). Before a router sends 
out an incremental update, it checks if the update is in a loop; if it is, then it is 
dropped. Fig 44b shows this process as Step (B), which is inserted between Fig 
44's Step (7) and Step (8). The reason for "cutting off loops" at this point, 
rather than earlier, before Step (5) when an update first reaches the router, is 

15 we want to leave the routing tables in a "loop state" so that it can be picked up 
by the "Routing Loop" Integrity Check, shown in Figure 73. 

A novel aspect of the invention's steady-state routing table computation 
is that it identifies routing loops. It is possible to configure the live routers so 
that they produce i) persistent, ii) periodic, or iii) transient routing loops for 

20 different destinations. Routing loops that result after the procedure in Figure 
44 terminates can be of any of these three types. By having an integrity check 
point presence of routing loops, the user can then look at the live routers to 
judge the severity of the problem. Clearly, persistent routing loops are the 
most severe and the transient loops are least severe. The severity of periodic 

25 routing loops depends on the frequency that the routing table destination is in 
"loop state" versus a non-loop state and whether the non-loop state results in 
correct routing or a no route condition. Many times, for periodic routes, the 
user may not be aware because he or she may poll the table while in a good 
state. Thus knowing about loops, which can be periodic, is valuable diagnostic 
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information. (Note: to be formally strict here, in the real routers there may not 
be a "steady-state" condition for some routing destinations, such as those 
involved in a periodic routing loop; for this particular case, our algorithm 
presents one of the cases, in the steady-state routing tables.) 

Another novel aspect of the invention stems form the fact that in some 
cases, the simulation "fleshes out the non-determinism" found in the live 
routers. For example, the actual routers can be configured to keep only up to 
two (equal cost paths) for each destination. If there happens to be more than 
two equal routes, two of them will be arbitrarily chosen. In contrast the 
invention can find all the equal cost paths to a destination D and show them all, 
reporting "two out of the following X paths will be chosen to destination D". 

Another contrast between the invention and live routers is that the 
invention exploits the fact that in its simulation model all the routers' models 
are in the same memory space, as opposed to a live network, where each router 
has its own memory space. For example, Step (9) in Figure 44 is a question 
that could be asked only if the routers where in the same memory space. It is a 
question that looks at global convergence. 

Recall that the processes in accordance with the invention have the 
ability to either import routing tables from the live routers or to calculate the 
routing tables based on information in the SROs and SPT's. In either case, 
once the routing table objects are populated, there are a number of integrity 
checks that can be applied. To see where in the overall process of the 
invention these routing table integrity checks are applied/refer to Figure lg. 

Before describing how the particular integrity checks operate, there are 
some preliminary concepts that need to be discussed. The routing tables, as we 
alluded to, are used by the routers when they receive a packet. When a host 
wants to forward a packet to another destination it will send it to its 
neighboring routers and that router, if it has a routing table element, will send 
to a next hop router en route to a final destination. So in this process, the 



WO 97/49214 



PCT/US96/10873 



-81- 

routers will send packets of data from hop to hop until they reach the 
destination. So in a sense, given a set of routing tables they implicitly define 
paths through the network going from a source to a destination. A concept 
that we'll define here is the notion as to whether given a source address and a 
5 destination address there is a path that exists throughout the network; and if 
there is, what path will be taken; and in a case where multiple paths can be 
taken what are these multiple paths. 

Figure 47 shows an example network that shall be used for explanation. 
In this example, there are five routers, R1 through R5. Rl and R2 are 

10 connected through an Ethernet (Conn[l]). Rl is connected to R2 through a 
serial link (Conn[2]). Router R2 is connected to Router R4 through a serial 
link Conn[3]. R3 and R4 are connected through an Ethernet (Conn[4]). R5 is 
isolated. It's just connected to an Ethernet (Conn[5]). Source Addresses and 
Destination Addresses, SA and DAI are respectively source and destination 

15 addresses on Conn[l], DA2 is a destination address on Conn[4] and DA3 is a 
destination address on Conn[5]. (Note: When we say source and destination 
address that's an arbitrary distinction. We say source address because it's used 
as a source in our example and destination address because it's used as a 
destination in our example. 

20 Continuing in Figure 47, the output for the analysis, which given a 

source address and destination address shall be called herein a "Completed Path 
Set." A Completed Path Set (CPS) will be empty if there is no path from SA 
to DA (where S A refers to the source address and DA refers to the destination 
address). If CPS has one element that means that there's one path from SA to 

25 DA and if it has more than one element there's multiple paths between the 

source and destination. For the example network, suppose we are considering 
a CPS (a Completed Path Set,) for a path from source address SA to DA2. In 
this case, there will be two paths, one of them that starts at SA and goes to 
Conn[l], Rl, Conn[2], R3, Conn[4] and then gets to the destination DA2. 
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The second path starts at SA, goes to Connfl], R2, Conn[3], R4, Conn[4] and 
then to DA2. If on the other hand, we are interested in a CPS where the 
source destination is SA and the destination address is DAI, (this is a case 
where the source and destination are on the same subnet), there would be one 
path; from SA to Conn[l] to DAI. An example where there is no path, is if a 
packet is to go from SA to DA3. In this case, CPS would be represented as an 
empty set. 

Figures 48a-48c depict a flow chart that the invention follows to 
produce a CPS, a completed path set, given a source address and a destination 
address. A novel aspect of this procedure is that it identifies multiple paths 
between source and destination and is performed off-line; this is in contrast, for 
example, with Cisco System's Path Tool, which is an on-line tool that only 
identifies the current path, not all the possible ones. An advantage of knowing 
all the paths is that the current one might be working while another possible 
path, which can be chosen at a later time, might have problems. The best way 
to present this is a walkthrough of a particular example. Refer now our 
attention on Figure 51, which is a generalized block diagram of a network very 
similar to the one in Figure 47, but with an added link, the link labeled Conn[5] 
between Rl and R4. Also, the router R5 we included in Figure 47 is omitted. 
The reason for including this link is to show what happens in the case of 
routing table element with multiple paths. In this example, a CPS will be 
produced in which the source address is SA and the destination address is DA. 

The input to the process of Figure 48 is the SPT for the protocol under 
consideration, so in this case, its an SPV Figure 52 shows the SPT ff that 
25 corresponds to Figure 51. 

Figure 53 shows the IP routing table for router Rl. The element 
labeled EL[1], has destination 10. 10.0.0 255.255.0.0. It has one cost-path, 
which corresponds to the fact that it is directly connected. Routing table 
element EL[2] corresponds to destination 199.28.77.0 255.255.255.0 and this 
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again is directly connected and corresponds to interface SO. Element EL[3], 
like elements EL[2] and element EL[1] corresponds to a directly connected 
interface. Element EL[4] is the only element out of the four which corresponds 
to a route that was dynamically learned. This corresponds to destination 
20.20.0.0 255.255.0.0. There are two cost-paths in the example, showing that 
there are two different ways to leave the router if a packet matches this 
element. The Cost Path element on the left indicates it was learned by RIP; it 
has a cost/administrative distance of 1/120. It's interface is SO. The next hop 
pointer is to router R3, SO and its interface connection is Conn[2]; the second 
cost-path object is also learned via RIP and has the same administrative 
distance as the first cost-path. This object specifies output interface SI, rather 
than SO. Its next hop pointer is R4,S1 and its interface connection is Conn[5]. 

Figure 54 shows an IP routing table object for R2. Figure 55 shows an 
IP routing table object for R3 and 55a shows an IP routing table for router R4. 

The flow chart in Figures 48a-48c shall be described in the context of 
the example by going through the walkthrough in conjunction with 
Figures 56a-56f. Starting in Figure 56a refer to reference numeral ( 1 ), which 
indicates that in Step (1) of the flowchart in Figure 46a the output produced is 
the CPS, is set to "empty". Step (2) asks whether there is a connection in the 
SPT^ (Note: in this example, P is IP because the example looks at a 
destination address and source which are both IP). The answer in this case 
"yes". If this was not the case, that meant that the source and destination were 
on subnets that the object model did not have and consequently the analysis 
could not proceed. If the answer is "yes", for convenience, at Step 3 the 
variable SC is set to the connection in the SPT which matches SA's subnet. So 
for this example SC is set to Conn[l] because SA is directly connected to the 
Ethernet labeled Conn[l ]. Step (4) sets DC (which is a variable referring to the 
destination's Conn) to the subnet matching DA; in this case it is Conn[4] 
because DA is directly connected to Conn[4], Step (5) asks whether SC equals 
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DC. In other words, are the source and destination on the same subnet? If that 
is the case, go to Step (6) and return a CPS with one element where the path is 
from SA, to the shared connection, to DA, a very simple path. If the answer is 
"no", which is the case in this example, go to Step (7) (labeled on Figure 48b) 
and initialize a variable called APS (for "active path set") to the path that is 
being constructed. In this case, there are two paths in progress. The first one 
starts at SA, goes to Connfl] and to router Rl, and the second one goes from 
SA to Connp] to router R2. In general, at Step (7), the procedure puts in as 
many elements as there are routers connected to the source's subnet. 

In Figure 56a, we show the progress of APS, which are paths that are 
incrementally building. So in this example, we can see that we have two paths 
shown by the dotted lines that both start at SA and one that ends at Rl and the 
other that ends at R2. As the process proceeds, it will be picking one of the 
elements in this set to extend by a hop and then puts it back in APS unless it 
1 5 gets to its destination the router that drops the packet or is involved in a 
routing loop. 

Now refer to Figure 56b, and more specifically to the reference therein 
to Step (8) (from the flowchart in Fig. 46b), which asks whether there are any 
elements (active paths) in APS. If it's "empty", the process terminates. If it is 
not empty, then proceed to Step (9). In this case, since the APS has two 
elements, proceed to Step (9). Step (9) sets the variable CP (for "current 
path") to one of the elements in APS and removes this element from APS. In 
the example, CP is set to the first path, which goes from SA to Conn[l] to 
router Rl. In Step (10) for convenience we are letting the variable, CR (for 
"current router"), refer to the last router in the path CP. In this case, the 
current router is Rl since there is only one router in the path. In Step (1 1) we 
ask, "does CR appear in the path more than once." This is a check to see if we 
are in a routing loop and to protect this procedure from being in an infinite 
loop. If CP refers to a loop, we add CP to the set of routing loop paths and 
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proceed by going back to Step (8) to see if there are any more paths to process 
in APS. If there is no loop, we go to Step (12) where we set a variable called 
CPO, standing for the Cost Path Objects, to the set of Cost Path objects 
associated with a routing table element that matches the destination address in 
5 the current router's routing table for the applicable protocol; IP in this case). If 
there are no elements matching DA and no gateway of last resort, CPO is set to 
null. 

The bottom of Figure 56b shows the cost paths that is set to CPO in 
Step (12). These are the two cost paths that are circled, the ones that are 

10 under element EL[4]. The details of how Step (12) is executed are depicted in 
the flowchart in Figure 50. In Figure 50, the input is a routing table (the 
routing table for the router and protocol under consideration - Router Rl and 
protocol IP in this example) and DA which refers to the destination address. In 
our example, the destination address is 20.20. 1.9. The output is the CPO, in 

15 other words a set of cost path objects that match the element DA. If there is 
no match, CPO will be empty. 

Let's walk through this flowchart. In Step (1) it asks are there any 
elements in the routing table that belong to the same major net as DA. For 
example/the major net that is associated with 20.20.0.0 is 20.0.0.0. (It's a 

20 Class A network address as opposed to being a Class B or Class C address). 
See, Martin, James, "Internet Address Formats", Local Area Networks 
Architectures and Implementations, pp. 439-440, PTR Prentice Hall, 1994. In 
Step (3) of Figure 50, we set EL to the element in the routing table belonging 
to the destination's major net having the most specific mask. The most specific 

25 mask is the one with the most 255s on the left. In this case, there is only one 
element in the routing table shown in Figure 56b belonging to net 20.0.0;0 and 
that is element EL [4]. Proceeding to Step (4) we ask, "does this element 
match the destination address?" We look at the destination in element EL[4] 
and we see the destination is 20.20.0.0 with mask 255.255.0.0. That means we 
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are looking for any destination that starts 20.20 and don't care about the last 
two octets. In our example this matches. So the answer at Step (4) is "yes" 
and the procedure exits, returning this element's cost path set which are the 
two circled cost paths in Figure 56b as output. If it didn't match, we would go 
to Step (5) and see if there are any other elements belonging to OA's major 
network which have a more general mask and then go back to Step (4) and try 
to apply the match. If the answer to Step (5) is "no" then we go to Step (2), 
which asks the question, "is there a gateway of last resort?" If it is, we return 
the CPO associated with it; if not, we return saying the CPO is empty. Also, 
we should note that in Step (1) if there are no matching elements in the routing 
table that belong to the same major net as DA, we go to Step (2) and look for 
gateway of last resort and return the CPO associated with it, if it is found; 
otherwise an empty CPO is returned. So in general, this procedure iterating, 
looking for the most specific match; if one is found, its CPO is returned. If we 
don't find any matches then we return the gateway of last resort's CPO if it 
exists. 

Let's continue the walkthrough at Figure 56c. To set the context, we 
had reached Step (12) as shown in 56b, which identified the CPO as being the 
circled items; in other words, the items under element EL[4] in Figure 56b. In 
Step (13), we ask the question, "is the CPO empty?" In this case, since there 
are two elements, the answer is "no" and we go on to Step (14). If it were the 
case that the CPO were "empty", meaning that there are no routes in the 
current router that match the destination address, then we are in a sense 
discarding this active path and going back to Step (8) to see if there are any 
more active paths to process. In our case, as we said, there was a match, so we 
go on to Step (14). In Step (14) and (15) we take one of the elements of the 
CPO, remove it, and set EL to the CPO we're processing. In this case, L is set 
to the CPO as depicted in Figure 56c, one CPO who's interface is set to SO. 
We next go to Step (16) which asks, "does the destination connection (DC) 
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match the EL's connection?" In other words, "are we pointed to the interface 
attached to the media on which the destination is connected?"; in this case, the 
answer is "no" because the destination connection is Conn[4], but the 
connection associated with EL is Conn[2]. So the answer at Step (16) is "No" 
5 and we go on to Step ( 1 7). In (17), the current path is extended with the 
element's Conn[2] (EL's interface Conn) and the next hop router R3 and put 
back in the set of active paths APS. The diagram in Fig. 56a pictorially shows 
the paths being developed that currently are in APS. 

The walkthrough continues at Figure 56d; after processing Step (17), 

10 we go back to Step (13) and see if there is (another) cost path object to 
process. In our example, since there was two paths out of the router 
associated with the matching routing table element, there is another cost path 
object to process. In Figure 56d, in the items marked (14) (1 5) we see that 
CPO is set to the cost path object who with interface is set to S 1 . We then go 

15 to (16) and ask the question, "does the connection associated with CPO, which 
in this case is Conn[5], match the destination connection Conn[4]. The answer 
is "No"; we haven't gotten to the destination connection. So we go back to 
Step (17) and add a new path to the APS. In this case it is the path that starts 
from SA to Conn[l] to Rl and this time rather than going out SO, we go out 

20 SI to Conn[5] to Router R4. The diagram in 5 6d depicts the three paths under 
construction that are on the APS after we execute Step (17). 

The walkthrough continues at Figure 56e. After processing Step (1 7) 
we go back to Step (13) and ask "is the CPO empty?" This time the answer is 
"yes, it is empty", so then we go to Steps 8 and 9 which refer to picking one 

25 element from the APS, if it is not empty, and seeing if we could add another 
hop to it in trying to reach the destination. So after going to Step (8) and 
getting the answer that APS is not empty, we go to Step (9) where we set CP 
to one of the elements in the APS. In this case we set it to the path labeled 
Path A in diagram 56d. Step 10 mentioned in Figure 56e refers to setting CR 
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to the last router in the current path, R4. We then go to Step ( 1 2), which looks 
through R4's IP routing table for a match to destination address DA. In this 
case, a matching element is found with a CPO that is depicted right after Steps 
(14) and (15) in Figure 56e. This CPO is a directly connected CPO, which 
means that the matching destination, which is Subnet 20.20.0.0 is directly 
connected. CPO's interface is set to E0, (Ethernet 0), since it is directly 
connected it does not have a next-hop pointer and associated connections, 
Conn[4]. We then go to (16) which asks the questions, "does the destination's 
connection, which is Conn[4], match the one on the CPO that we are 
processing? The answer here is "yes". So, after Step (16) we go to Step (18) 
which is the first time in this example, we have added to the CPS; thus, we 
have reached the destination; the path that gets added to the CPS is one that 
goes from SA to Connfl] to Router Rl to Conn[5] to Router R4, out Conn[4] 
to the destination address. 

After Step (18) processing goes to Step (13), which returns "yes" since 
there are no more cost path objects to process; consequently, the algorithm 
goes to Step (8). At Step (8), the APS has the two paths shown in Figure 56f. 
This processing of elements in the APS repeats itself; the end result will be that 
the CPS has 3 elements which are shown in the computer form at the bottom of 
Figure 56f and shown in the diagram in the middle of Figure 56f, the paths are 
from SA to Conn[l] to Rl to Conn[2] to R3 to Conn[4] to DA; from SA to 
Conn[ 1 ] to Rl to Conn[5] to R4 to Conn[4] to DA, and from S A to Conn[ 1 ] 
to R2 to Connf3] to R4 to Conn[4] to DA. 

One of the complications that we have to take into account in 
constructing the CPS is that the routers might have both input and output 
access lists. These, as we described before, are filters that can block traffic 
coming into the router (an input port filter) or going out of the router (an 
output port filter). If the procedure runs into an access list that blocks the path 
being constructed, then it will not put it into CPS. 
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Figure 57 shows, in attribute form, an access list. An access list is 
indexed with a Number as an identifier. Access lists are maintained on the 
router and since the same access list may be used on a variety of ports, each 
port refers to it's associated access list by the identifier (Number), rather than 
5 redundantly storing the whole access list. The main part of an access list is its 
element objects. Access lists are processed by going from the first element 
down to the next element looking for a match, and if there is a match and the 
matching element has a permit action, the packet being matched gets through. 
If the matching element then has a "deny" action the matching packet does not 

1 0 get through. If all the elements in an access list is reached and no match is 
found, then the packet is blocked. What "matching" means depends on the 
protocol. For IP, the conditions for a match are as follows. For example, 
consider an element with the address set to 10.0.0.0 and the mask set to 
0.255.255.255: For an access list element, 0 means consider the corresponding 

15 octet, while 255 means ignore it; so this pattern would match anything that 
starts with Octet 10 and match it regardless of what the last 3 octets are. 
Similarly, if the access list's address and mask were 10.20.0.0 and 0.0.25.25 
respectively, this pattern would match anything that starts with a 10.20 
regardless of the last 2 octets. 

20 Figure 58 presents the flow chart that the invention follows to see if the 

addresses matches an access list Accl. In Step (1), we set EL to the first 
element in the access list. In Step (2) we ask, "does the address (addr) match 
the EL's address, given the elements mask. If the answer is "no", we go to 
Step (4) where we ask, is this the last element? If this is the case the process 

25 terminates saying that the status is "blocked". If the answer is "no", we set EL 
to the next element in the access list and proceed by going to Step (2). If the 
answer to Step (2) was "yes", then we ask the question, is the action associated 
with the matching element a "permit"? If the answer is "yes", then the process 
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exits saying the status is "accepting". If the answer is "no", the process exits 
with status blocked. 

As we mentioned, a complication that we have to factor into the 
flowchart in Figure 48a-48c taking into account the access lists on both input 
and output ports. In Figure 59 we show how we patch into Flowchart on Fig. 
48 the logic that is need to process input access lists and in Figure 60 we show 
how we further patch this flowchart to take into account output access lists. 

The process shown in Figure 59 is put in place starting from Step (11) 
in Figure 48b. When we are at Step (7) in Figure 48b, we are at the state 
where we take a path off the APS list and set CR to the current router, which is 
the router last in the path. After going to Step (1 1), rather than going directly 
to Step (12), we go to Step (A) as labeled in Figure 59 and we set input port to 
the port on the current router pointed to by the connection in the current path 
right proceeding CR. So for the example you saw in Figure 48b it would be 
the port that is connected to R5 that is pointed to by Conn[2]. Given this input 
port, we ask, "does this input port have an access list for the protocol under 
consideration?" So for our last example, it would be IP. If the answer is "no", 
we proceed as we did in the earlier example and go to Step ( 1 2). If the answer 
is "yes", then we ask at Step C, does the matching access list block the 
destination address (DA). If the answer is "no" (it doesn't block it), the packet 
gets through and proceed as normal and go on to Step (12). If it does block 
the packet then we go to Step (8) in 48b, which effectively means ignore the 
path being processed because we took it out of the APS; that is, by just going 
right to Step (8), we are dropping this path and going to the next one. 

Figure 60 shows the modification we make to the flowchart in Figures 
48a through 48c, to handle the complication of encountering output access 
lists. This process is integrated in at Step (15) in Figure 48c. Setting context, 
after the point that we are processing an active path, we identify the current 
router; we then look to see if there is a matching element in its routing table 
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that matches the destination address. If that is the case, then we set CPO to the 
set which shows how to get out the router. Then we set EL to the, one of 
these elements. Step (1 5) is at the state where we have a path (given by EL) 
out of the router. EL identifies a particular port, so in Step (A) we set output 
to the port mentioned by EL. Then we ask the question in Step (B), "does the 
output port have an access list for protocol P?" If the answer is "no", we 
proceed, doing nothing, and go to Step (16); if the answer is "yes" we try to 
match the destination address against the access list. If the answer is that it 
doesn't block it, we proceed as normal and go to Step (16), if the answer is it 
does block, then we go straight to Step (13), which has the effect of rejecting 
the path out of the current router given by EL. So for example, if you found a 
matching element with two ways out of the router, and both of them have 
access lists that block it, then we will drop all paths for the destination DA that 
go into the router. 

Note that although an example has been provided in which matching 
takes place on destination address, matching can take place on other values as 
well. For example, as alternatives, matching can occur on the source address, 
the ports associated with a TCP packet, etc. So there are many conditions that 
can be applied and tested during the filtering. For the sake of illustration only, 
matching on the destination address was discussed above. 

Figure 61 depicts a graft to the flow chart for finding network paths 
(Figures 48a-c) to handle paths addressed to routers. To set context, at Step 
(1) in Figure 48b, the procedure is at the stage where it is processing a path in 
the active path set (APS), referred to by CP and has just assigned the variable 
CR to the last router in this path. In Figure 61, processing (for the graft) goes 
from Step 10 to Step (A), which determines whether the destination address 
DA exactly matches any of CRs port addresses. If the answer is "yes", then the 
path being processed is one that is addressed to router CR; consequently, 
processing moves to Step (B) where the path [CP;DA] (i.e., the active path, 
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which has reached router CR, annotated with the destination address DA) is 
put into CPS, the set of completed paths; next processing goes to Step (8), 
shown in Figure 48b, which checks if there is another active path to process. 
If at Step (A), the algorithm determines that the path is not addressed 
5 to router CR, processing continues as it would have for the non-grafted 
algorithm; that is, processing moves to Step (11), shown in Figure 48b. 

Figure 62 depicts a variant of the flowchart for finding network paths 
(Figures 48a-c) to handle paths starting at a router. The input to this procedure 
is a reference to a router R, a destination address DA, the SPT for the protocol 

1 0 associated with DA, the set of SROs that the SPT points to, and the routing 
tables (for the associated protocol) for each of the routers. In Step (A), the 
output set CPS, for Completed Path Set, is initialized to empty and at Step (B), 
the output RLPS, for Routing Loop Path Set, is set to empty. Step (C) checks 
whether the destination address has a connection in the SPT associated with it; 

15 if not, then processing terminates; otherwise Step (D) is reached where DC is 
set to the connection in SPT that address DA is associated with. At Step (E), 
the variable APS, for Active Path Set, is set to be a single element denoting a 
path starting at router R; processing then continues at Step (9), shown in 
Figure 48b, which is the step in the main algorithm, which chooses a member of 

20 APS to process (that is, to try to extend to the destination address). Because 

there is only one element in APS, in Step (9), CP is set to that element (i.e., the 

path being "starting at R"). 

We have now described the process of, given a SPT the routing tables, 

a destination address and a source address, determining whether there exists 
25 one or more paths through the network. This is basic function that we are 

going to use in the following section, which describes the routing table integrity 

checks (Figure 1). 

In the general case, whether two hosts should communicate is an 

organizational specific need. There is no general rule saying this host should 
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talk to this host. So we are introducing here a new type of integrity check 
where the user supplies an input, namely, the set of source and destination 
address that should communicate and the set of ones that should not. Given 
this set of "connection requirements", the invention simply applies the CPS 
algorithm to find if the source-destination pairs that should communicate have 
a CPS with one or more elements and the pairs that should not communicate 
produce an empty CPS. If the invention is given the connectivity requirement, 
SA should talk to DA and CPS is computed to be empty, then that is an 
integrity violation to be presented to the user. Conversely, if there is a 
requirement that SA should not be able to reach DA, but we find that there is a 
path, then we present this violation to the user. 

Figure 72 depicts the process for computing the "User Specified 
Requirements" integrity check; the input to this process is a source address SA, 
destination address DA, a TYPE variable, which is set to "Permit" or "Block" 
and the routing tables objects for each router in the list of SROs. The output is 
the state "OK" or "Violation". If TYPE is set to Permit then the output will be 
OK if and only if one or more paths exist from the source SA to the destination 
DA; conversely, if TYPE is set to Block then the output will be OK if and only 
if no paths exist from the source SA to the destination DA. 

In Step (1 ) of the flowchart (Figure 72), the procedure calls the 
subfimction described by the flowchart in 48a-c, which determines whether 
there is a path from a source address to a destination address given as input; if 
there is a path, then the output CPS, which is a set, will be non-empty (and 
contain the path(s)). At Step (1), the input to this procedure is SA as the 
source address and DA as the destination address. If the output (CPS) is 
empty, then there is no path and processing moves to Step (2), which returns 
Violation if TYPE is Permit and OK otherwise (i.e., when TYPE is set to 
Block). If CPS in Step (1) is not empty, then processing moves to Step (3), 
which returns OK if TYPE is Permit and Violation otherwise. 



WO 97/49214 



PCT7US96/10873 



-94- 



10 



15 



20 



25 



The integrity check just presented above required the user to give the 
pa,rs of source and destination addresses and specify whether or whether or not 
they should communicate, since this is a organization specific requirement The 
mtegrity checks prior to this were ones that were applicable regardless of the 
orgamzauon. These are typically patterns, if found, in the network are 
problems. For the case of paths, there are some examples (i.e. routing table 
mtegnty checks) where we have integrity checks that do not require asking the 
user to supply sourC e and destination addresses. By virtue of some of the 
configurations of other options in the router, there are implicit requirements 
about routers that must communicate. One example relates to Remote Source 
Route Bridging (RSRB), when routers are configured to encapsulate source 
route bndge traffic (which is inherently OSI Model level 2) over an IP 
backbone. To do so, a set of routers are designated as SRB peers and within 
each of these routers' configuration there is a mention of peers that it needs to 
communicate with. By design, for example, these routers need to talk to each 
other over, for example, a TCP connection. Note the example in Figure 67 
68a and 68b. This is an example of a network where we have two routers 
router Rl and R6 that are configured as source route bridge peers. Router R, 
mennons the address of router R6 and conversely R6 mentions an address 
assorted with Rl saying that they are source route bridging peers and that 
they should talk using TCP. 

Reiterating, the routers communicate with TCP. So by virtue of the 
configuration you see in Figure 68a and 68b (or looking in Figure 69 where we 
show the RSRB fragments that are found on the SRO's of Rl and R6 
respectively) we know that these routers should be able to communicate In 
other words, we know there should be a path from router Rl to router R6 and 
v.ce versa. So there should be a path from 30.50.2. 1 to 50.7.8.3, a path from 
Rl to R6, in both directions. So without asking the user which hosts or which 
routers should communicate we are able to automatically infer connectivity 
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requirements. So the integrity check associated with source route bridging 
simply looks at all the routers for RSRB peer statements and then applies the 
CPS algorithm for each of the routers that should peer together to find out if 
there is one or more path. If there is no path, for a RSRB pair, then an 
5 integrity violation is given to the user showing you, for example, that Rl and 
R6 cannot communicate although they are set up as RSRB peers. 

There are a number of examples of these integrity checks that the 
invention includes. Another example stems from the use of the routing 
protocol BGP, which can mention a neighbor router which could be many hops 

1 0 away. In this case, by virtue of having the configuration mention a neighbor, 
we come up with a connectivity requirement saying that the router should be 
able to find a path to the neighbor. Another example is the use of static routes 
that mention an address that is not directly connected, and could be many hops 
away. In this situation we want to make sure that there is a one-way path from 

1 5 the router to the address that is mentioned. If there is any cases where we have 
a static route not having this property, a violation is flagged. So, in summary, 
by virtue of configuration, we are able to infer a number of connectivity 
requirements, and if these connectivity requirements are failed, the user is given 
a list of the violations. 

20 Figure 70 depicts the process for computing the "RSRB/DLSW Peer" 

integrity check; the input to this process is the SROs and routing tables objects 
for each router in the list of SROs. The output is the set Conflicts, which 
contains <Router, Remote Peer object>; if <R1,P1> is in Conflicts, this means 
that a connection cannot be established from router Rl to the address of the 

25 remote peer mentioned in PI . 

In Step (1) of the flowchart in Figure 70, the output Conflicts is 
initialized as an empty set. At Step (2), the variable R is set to the first router in 
the list of SROs and at Step (3), the question is asked whether R has any 
remote DLSW or RSRB peers. If the answer is "no", then processing moves to 
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Step (4) to determine if there are any more routers that need processing; if 
there are more routers to process, then the algorithm goes to Step (5), setting 
R to the next router, and then to Step (3) to process this new router If the 
answer to Step (3) is « yes » (i.e., router R has DLSW and/or RSRB peers) then 
processing moves to Step (6) where variable P is set to the first RSRB or 
DLSW remote peer object in R. 

At Step (7), the procedure calls the subfunction described by the 
flowchart in 62, which determines whether there is a path from a router given 
as input to a destination given as input; if there is a path, then the output CPS, 
which is a set, will be non-empty (and contain the path(s)). At Step (7), the ' 
input to this procedure is R as the input router and the address mentioned in P 
as the destination address. If the output (CPS) is empty, then there is no path 
and processing moves to Step (8) where the pair consisting of R and P is put in 
the set Conflicts; processing next continues at Step (9), which checks whether 
R has any more RSRB or DLSW peers needing processing; if there are more 
remote peers to process, then the algorithm sets P to the next remote peer (at 
Step (10) and then moves to Step (7) to process this new peer. Now, if at Step 
(7), the result of computing CPS yields a non-empty set (i.e. there is a path 
from R to P's remote address), then processing goes straight to Step (9). 

Figure 71 depicts the process for computing the "BGP Neighbor- 
integrity check; the input to this process is the SROs and routing tables objects 
for each router in the list of SROs. The output is the set Conflicts, which 
contains <Router, BGP Neighbor object>; if <R1,N1> is in Conflicts, this 
means that a connection cannot be established from router R] to the address of 
25 the neighbor mentioned in Nl . 

In Step (1) of the flowchart in Figure 71, the output Conflicts is 
initialized as an empty set. At Step (2), the variable R is set to the first router in 
the list of SROs and at Step (3), the question is asked whether R has A BGP 
process running. If the answer is "no", then processing moves to Step (4) to 
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determine if there are any more routers that need processing; if there are more 
routers to process, then the algorithm goes to Step (5), setting R to the next 
router, and then to Step (3) to process this new router. If the answer to Step 
(3) is "yes" (i.e., router R has A BGP processing running), then processing 
5 moves to Step (6) where variable N is set to the first BGP neighbor object in 
R's BGP object. 

At Step (6a), the invention checks whether N's address refers to a 
remote (i.e, more than 1 hop away router); if it does not, this neighbor does not 
need processing, and the algorithm moves to Step (9), which checks whether R 

10 has any more BGP Neighbor Objects to process; if there are more BGP 

process, then the algorithm sets P to the next remote peer (at Step (10) and 
then moves to Step (7) to process this new peer. Now, if at Step(6) it is 
determined that N has a remote address then processing goes to Step (7). 
At Step (7), the procedure calls the subfiinction described by the 

1 5 flowchart in 62, which determines whether there is a path from a router given 
as input to a destination given as input; At Step (7), the input to this procedure 
is R as the input router and the address mentioned in N as the destination 
address. If the output (CPS) is empty, then there is no path and processing 
moves to Step (8) where the pair consisting of R and N is put in the set 

20 Conflicts; processing next continues at Step (9) to process the next BGP 

Neighbor object with a remote address (if one exists). Now, if at Step (7), the 
result of computing CPS yields a non-empty set (i.e, there is a path from R to 
P's remote address), then processing goes straight to Step (9) ; 

Figure 73 shows the invention's process for finding all routing loops for 

25 a protocol P. The input to this procedure is a SPT for protocol P, the list of 

SROs it points to and the set of routing tables for protocol P for each router in 
the list of SROs. The output is the set Routing_Loops which contains elements 
of the form <Conn,Pth> where Conn is a connection in the SPT and Pth is a 
path through the network having a routing loop for hosts on connection Conn. 
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In Step (!) of the flowchart i„ diagram 73, the output Routir, s loop, , s 
« .0 empty. At Step (2,, .he variable R is set ,o the firs, router i„ theta „f 

SROs given as input. 

Step (3) checks whether there are any connections in the SPT for 
protocol P not direct.y attached to R. The reason for asking this question is 
because the algorithm will be trying to reach all connections from each router 
and there is no need to consider directly connected ones since they are triviaHy 
reachable. If the answer to Step (3) is "no" (i.e., all connections in SPT are 
connected to R, the processing moves to Step (4), which checks to see if the 
last router has been reached; if so, the process terminates; if not, processing 
moves to Step (5) where R is set to the next router (in the list of SROs) and the 
process repeats itself for this new router. 

If the answer to Step (3) is "yes" then processing m0V es to Step (6) 
where variable C is set to the first connection in SPT that is not directly 
attached to R. Next, at Step (7), there is a check to see if. routing loop with 
connection C and Router R has already be found (which can happen for 
example, if there was an earlier router processed which in going to C went 
through R and ended in a loop). If . bop has already been found, there is no 
need to process Connection C starting at router R and thus execution continues 
at Step (8); at this, the invention checks whether there are any more 
connections (not directly attached to R) left to process; if so, processing goes 
to Step (9) where C is set to the next applicable connection and then 
processing continues for this new connection (sti.l using router R as the starting 
P0.nt); on the other hand, if the answer to Step (6) is "no" (i.e., there are no 
more connection to process), then the procedure goes to Step (4) to see if 
there are any routers left to process. 

Now, going back to Step (7); if the answer at this step is "no" meaning 
that a routing loop involving connection C and router R has not yet been 
found, then processing moves to Step (1). At Step (10), the procedure calls the 
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subfiinction described by the flowchart in 62, which determines whether there 
is a path from a router given as input to a destination address given as input 
and if not whether there is a routing loop; At Step (7), the input to this 
procedure is R, as the input router and C, the destination connection, which is 
5 given in place of a destination address, (note: It is trivial modification of Figure 
62 to use a destination connection, rather than a destination address, as input 
because essentially the only role of the destination address in the CPS 
procedure is as a handle at getting the destination connection (see Step (D) in 
Figure 62.)) 

1 0 The result of the CPS computation at Step (7) will be both the CPS 

output and the routing loop set (RLPS) which will be empty if no routing loops 
are found. If RLPS is empty, then no problem has been found, and processing 
continues at Step (8), which checks if there is another connection to process 
(starting at router R), If RLPS is not empty, then processing goes to Step (11), 

1 5 where all the routing loop paths contained in RLPS are added to the output 
Routing Loops, each annotated with the destination connection that they are 
associated with (i.e. the connection C); processing then continues at Step (8). 

While particular implementations of a presently preferred embodiment 
of the invention have been disclosed, described and illustrated in detail, it will 

20 be appreciated that various modifications to the preferred embodiment can be 
made without departing from the spirit and scope of the invention which is 
defined in the appended claims. 
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WHATrsnrMMfPTfr 

1 • A method of managing a computer network comprising the steps of 
providing respective router configuration information in executable 

form; 

producing respective Structured Router Objects (SROs) that are 
respectively associated with respective router configuration information and 
that respectively organize associated information in executable form in 
respective structures in electronic memory; and 

producing respective Single Protocol Topology (SPT) objects in 
electronic memory, each respectively associated with a different respective 
single protocol and each respectively interrelating SROs associated with the 
same respective single protocol. 
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version 10.0 
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hostname R1 
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noveU routing 0000.0c08.94dd 
! 

interface EthemetO (V) 

ip address 10.30.7.225^255.0.0 

ipx network 9c 

interface SeriaiO (^) 

ip address 10.10.4.1 255.255.0.0 

ipx network 7a 

bandwidth 1000 
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network 10.0.0.0 
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version 10.0 
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hostname R2 
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i 
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ip address 10.20.5.2 255.255.0.0 
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interface SeriaiO 

ip address 10.10.4.2255.255.0.0 
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router igrp 109 
network 10.0.0.0 
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p 70.70.3.0 255.255.0.0 199.37.28.3 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



[Object Type: Router 
Hostname R1 



Ports* 



PCT/US96/10873- 



8/98 



FIG. 7a 




Media Type: Ethernet 



Number: 0 



Encapsulation: ARP 



Bandwidth: 1000 



Delay: 100 



Port Addresses* 



Port [2J: SO 



Media Type Serial 



Encapsulation: HDLC 



Bandwidth: 1000 



Delay: 2000 



Port Addresses • 




Port_addr[1](R1,E0,IP1) 



Protocol: IP 



Address: 10.30.7.2 255.255.0.0 



0 



Port_addr[1j (R1,S0,IP1) 



Protocol: IP 



Address: 10.10.4.1 255.255.0.0 



Port_addr[2] (R1,S0,IPX1) 



Protocot IPX 



Address: 9c 



Protocols 



Port_addr[2] (R1,S0,IPX1) 



Protocol: IPX 



Address: 7a 



Protocol [1] 



Type: IGRP 109 



Networks* 



Static Routes: EMPTY I |Net_addn 10.0.0.0 



Access Lists: EMPTY 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCTAJS96/10873- 



9/98 



Object Type: Router 



Hostname: R2 



Ports* 



FIG. 7b 




Media Type: Serial 



Number. 0 



Encapsulation: HDLC 
Bandwidth: 1544 



Delay: 2000 



Port Addresses' 



Port_addr[1](R2,S0,IP1) 



Protocol: IP 



Address: 10.10.4.2 255.255.0.0 

X 



to 



Port_addr[2] (R2,S0,IPX1) 



Protocol: IPX 



Address: 7a 



Protocols 



Protocol[1] 



Type: IGRP109 



Networks* 



Static Routes: EMPTY 



Net addr: 10.0.0.0 



Access Lists: EMPTY 



Port[2]:E0 



Media Type: Etherne t 
Number 0 



Encapsulation: ARP 



Bandwidth: 10000 



Delay: 100 



Port Addresses* 




Port addr[1] (R2,E0,IP1) 



Protocol: IP 



Address: 10.20.5.2 255.255.0.0 



Port_addr[2] (R1,S0,IPX1) 



Protocol: IPX 



Address: 98 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



FIG. 8a 



Object Type: SPT 



Protocot IP 



Conns: [Empty] 



RG. 8b 



Object Type: SPT 



Protocol: IP 



Cams: 



Object Type: Cqnnjll 
Subnet 10m0~0 



Pointers: [Empty] 



PCT/US96/10873 



10/98 



Q Initialized SPT set to 
EMPTY 



PA assigned 
10.30.7.2255.255.0.0 



(7Y (SubnetKPA))- N 
10.30.0.0 and is not In 
SPT 



Qr First 'connection' 
(SubnetKPA)) added to 
SPTp 



FIG. 8c 



Object Type: SPT 



Protocol: IP 



Conns: 



Object Type: Connlll 



Subnet 10.30.0.0 



Pointers: 



.POJNTBR_ 

Rimipi 



0 



' Pointer to PA > 
(R1,E0JP1) added under 

subnet 10.30.0.0 in 
^ SPTp j 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



FIG.8d 



Object Type: SPT 



Protocol: IP 



Corns: 



Object Type: ConnMl 



Subnet 10.30.0.0 



Pointers: 



R1J0.P1 



FiaSe 



Object Type: SPT 



Protocol: IP 



Conns: 



11/98 



a 



PCTAJS96/10873 

PA notlast > 
address 



i Object Type: Connj2] 

aSetioTap" 

Pointers: 



Object Type: Conn(2l 



Object Type: Connlll 



Subnet 10.30.0.0 



Pointers: 



Subnet 10.10.0.0 



Pokiters: 



POINTER 



R1,BD,lP1 



TOM,. 



PA assigned 
10.10.4.1 255.255.0.0 

(Subnetip(PA)) = N 
10.10.0.0 and is not in 
SPT,p y 

Qfe Subnet encountered^ 
new connection added to 
I SPT 




r Pointer to PA > 
(R1,S0,iP1) added under 
subnet 10.10.0.0 in 

v SPTip j 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 

PCT/US96/10873 



Object Type: SPT 



12/98 



(7^ PA not last address 



PA assigned ^ 
10.10.4.2255.255.0.0 



/pj (Subnet( P (PA)) = 
10.10.0.0 is inSPTip 

r^fT 1 Port Address PokiteT) 
\-A for Subnet 10.10.0.0 
added to SPT J 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 



13/98 



FIG.8h 




Object Type: Coring) 



Object Type: Cqnn[2l 



Object Type: ConnHI 



Subnet 10,30.0.0 



Pointers: 



Subnet: 10.10.0.0 



Pointers: 



POINTER 



R1,ED,IP1 



Subnet 10.20.0.0 



Pointers: 



J POME? 
— RZS0.P1 



R1.SUP1 



RZE0.IP1 



\y 



N/f ort Address for Subnet 1 



f/asi 



10.20.0.0 encountered, 
^pointer added to SPT^ 



Object Type: SPT 



Protocol: IP 



Conns: 



0 



Last Port Address 
encountered: SPT for IP 
complete 




Object Type: ConnPl 



Object Type: Conngj 



Object Type: Gonnlll 



Subnet 10.30.0.0 



Pointers: 



Subnet: 10.10.0.0 



Pointers: 



POINTER 



RW 



Subnet 10.20.0.0 



Pointers: 



POINTER 



RZS0.IP1 



POINTER 



R1.SOJP1 

\y 



POINTER 



RZHUP1 

\y 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 



14/98 



Object Type: SPT 
Protocol: IPX 



Conns: 




Object Type: Connlll 

Subnet: 9c 



Pointers: 



powter 



R1.E0,iPX 



Object type: Connl3l 



Object Type: Connf21 



Subnet: 7a 



Pointers: 





1 POINTER 




R7S0.IPX 


POINTER 




R1MIPX 


J 



Subnet 98 



Pointers: 



POINTER 



RZE0,IPX 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 



1998 



FIG. 9 




Initialize the output SPTp to 
empty 



o 



Set DuplAddrSet to EMPTY 



Initialize PA to the first Port Address 
of the first router in the list for 



Pro' 



( Each distinct (sub)net 
is added to the SPT as 
a "connection" 



Ocolg 



© 



Si 



Add a set containing PA and 
the port addresses in the 
matching SPT exactly 
matching PA as a new 
element of DuplAddrSet 



AddSubnetp(PA)to 
SPTp 




Add pointer to PA under the 
connection in SPT matching 
Subnetp(PA) 




Add PA to this matching 
member in DuplAddrSet (which 
is a set of Port Addresses) 




SUBSTITUTE SHEET (RULE 26) 




As referred to in tte Flowchart the term "DuplAddrSet" connotes a set of Port 
Address Sets that capture the port addresses that exactly match. 

For example {{Pa1,Pa3,Pa4} {Pa9,Pa7}} means Pa1,Pa3,&Pa4all refer 
to the exact same address and Pa9 & Pa7 refer to exactly the same 
\address. 



Input: SPTp, where Pis IP or> 
AppleTalk 

Output: Conflicts: Set containing 
sets of Conns in SPTp that are 

01 




FIG. 10 



Iriitiaize the output Conflicts to EMPTY 



Initialize Conn to the second 
connection in SPTip 



0 



For any connection C2 in SPTp before Conn if 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873. 



17198 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873 



FIG. 11 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 



19/98 



Object Type: View (VW) 



Type: Campus 



Groups 



Name: C1 (T) 



Com 



POINTER 



conn[3] 



Router List 



POINTER 



R1 



FIG. 12 




(T ^Narng C2 



Conn • 



]© 



(%] Name: C3 



Conn 



POINTER 



connfl] 



Router List • 





Router List 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 




Create anew group and new 
campus number and add pointer to 



al routers in Com and pointer to 
Conn 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873 



21/98 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCIYUS96/10873 



Object Type: View 



Type: OSPF 



Groups 



22/98 



FIG. 15 



Name: AreaO 



Conn 





POINTER 



POWTER 



POINTER 



conn[1J \y 



nn[3] 



Router List 





Name: AreaO Area! 



Conn • EMPTY 



Router List 




Router List 



/ POINTER 


POINTER 




R5 


y 



POINTER 



R4 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



Object Type: Router 



Hostname: R1 



Ports • 



;PortJ]. 



Protocols: 



Protocol: 0SPF1 



Type 



Net addr 



(T) |Addn 99.30&^0.0.255.255 Area 0 ( u) |Addn 99.30.0.0^0.0.255.255 Area 0 



PCT/US96/10873 



23/98 



FIG. J 6a 



Object Type: Router 



Hostname R2 



Ports • 



[PprtlNL 



Protocols: 



Protocol: 0SPF1 



Type 



Net addr* 



Addr: 10.20.0.0 0.0255.255 Area 0 



0 



Addn 20.20.0.0 0.0.255.255 Area 0 



Object Type: Router 



Hostname R3 
Ports* 



PortIN] 



Object Type: Router 



Hostname R4 
Ports* 



■Port IN] 



Protocols: 



Protocol: 0SPF1 



Type 



Net addr* 



T 



Protocols: 



Protocol: 0SPF1 



Type 



Net addr* 



/^ote: Border^ 
Router With 
AreasO&l 



Addn 20.20.0.0 0.0255.255 Area 0 1 9840-0-0 0-0-255255 Area 1 ^ 



(^]Addn 20.20.0.0 0.0.255.255 Area? 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCTYUS96/10873 



24/98 



Object Type: Router 



Hostname: R5 
Ports* 

iPortTsO] 



FIG. 16b 



Object Type: Router 



Hostname: R6 
Ports* 

SPflrtW"""" 



Protocols: 



X 



Protocols: 



Protocol: 0SPF1 



Type 



Net addn 



Protocol: 0SPF1 



Type: 



addr • 



I 



Addr: 98.40.0.0 Q.0.255.255 Area 1 |Addn 30.0.0.0 0.255.255.255 Area 1 



a02! 



Addr 30. 0.0.0 0.255.255.255 Area 1 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873 



Object Type: SPT 



Protocol: IP 



25/98 



FIG. 17 



Object type: Comfl] 



Subnet 20.20.0.0 



Pointers* 




POINTER 



POINTER 



R4.FW 



R3.F1.P1 



Object \Type: Conn[2\ 




Subnei 99.30.0,0 


Pointer^* 




Object Type Conn[3] 


Subnet 10.20.0.0 


/ POINTER \ 


Pointers* 



POINTER 



POUTER 



Object Type: Conn[6] 


Subnet: a 


10,40.0.0 


Pointers 


• 














POINTER 






R6LE1,IP1 





Object Type Coratf] 



Subnet 30.30.0.0 



Pointers* 



Object Type Conn[4] 



Subnet 98.40.0.0 



Pointers' 





POINTER 






POINTER 




R4S0,IP1 



Object Type Conn[5] 



Subnet 30.20.0.0 





POINTER 




RBJDJP! 


POINTER 




R5J0UP1 



POINTER 
R5^1,(P1 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



/tfOTE:OSPF conflict 
occur when adjacent 
routers assign drfferent 
areas to the same 
connection (subnet) 



26/98 
START 




(7^ Initialize VW to EMPTY 
with TYPE = OSPF 



I 



initialize OSPF_Confficts to Empty 



PCT/USW/10873- 



Notes: 

Input to this process is SPTip 
(OSPF only runs with IP) 

Output is the View Object 
(VW) 





Set Conn to first Connection in SPTip 




Set Com to next connection 
inSPTip 

r ' 


t Set AreaSet to set of areas associated - 
with Conn's pointers (ref . Fig. 1 9) i 



FIG. 18 



3 




0. 



> = 1 

w — ; » 


Let Area Ar be the single 




areainAreaSet 



Put (Conn, AreaSet) 
in OSPF Conflicts 



SetPNTRto 
first pointer in 
Conn 




Add 
"Area_Ar"to 
VWand 
pointer to 



Add pointer to 
Conn under 
"Area Ar" 



18. 



A 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 



SetPNTRto 
next (xiintra' in 
Conn 



® 




27/98 



Router — r 13J 
pointed to by 
PNTR processed 



No 

HowN/ 14 
Inany areas doesS^ >] 
the router pointed to 
by PNTR have? 
(ref.Rg.2Q). 



1 



FIG. W(contd) 



Create a new group 
T3order_Area»Area»" 
and under this group add 
pointer to router and to 
route pointed to by PNTR 



Add Pointer to router 
pointed to by PNTR under 
"AreaAr" 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



28/98 



Setpntrtonext ponterinConn 





Let OSPF obj refer to OSPF 
object associated with OSPF 

configured on router associated 

withpntr 



PCT/US96/10873- 



FIG. 19 



Notes: 

Input to this process is: 
Cdm_Ar 
(an IP Connection) 

Output is: AreaSet 
(set of OSPF Areas with which 
router ports on Conn are 
associated) 



Si 




LetNetstmtbenext 
network statement in 
OSPFobj 



Let netstmtbe first network T) 
statement in OSPF ofaj ^ 




1\let_addrinSR0or 
network statement in 
Confkjie 



Add area mentioned in 
netstmtto AreaSet if it k — N 
is not already there 
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Let OSPF obj refer to OSPF object 
associated with OSPF configured on router 



T 
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Object Type: MPT 



MpCs (Multiprotocol Conxn's) 



FIR 21 




Object Type: MpCIl] 



| Object Type: Mpjj 



Subnet [1] 



Subnet: [1] 
Subnet [N] W7rr 



Pointers < 



Subnet IN] 
Pointers • 







,. 11 
POINTER 




Rt,Po 



fox = Router 

Po - Port 

V 



name 
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/*Note: Inputs to this process^ 
areSPTipandSPTiPx 
Outputs are: MPT & 
Mismatch Set 



FIG.22 




I 



Set output (MPT) to empty jT) 



Set Mismatch to empty 



Set C to First Connection In 
SPTip 



Add to MPT a MpC 
corresponding to C 




SetC to Next 
Connection in SPTip 



SetC to 1st IPX 
Connection in SPTipx 
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FIG. 22 '(Cont'd) 



Add to MPT a MpC 
CdrfespondlngtoC 



'completely 
| no match or 

SUBSET 
RELATIONSHIP 




(( SEE FIGURE 23 
FOR EXPLODED 
VIEW 



COMPLETE 
MATCH 



AddCSubnettothe 
matching MpC 



Mismatch 



Add SPT Info to 
Mismatch Set 



Set C to Next IPX 
Connection 




3 



© 
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Object Type: MPT 



MpCs: [EMPTY] 



FIG. 24b 
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Note: Inputs to this process are: 
SPTpandSPTiRx 



Output MPT Set 
- EMPTY 



3 



Object Type: MPT 


MpCs: 








: Object Type: 


MpCil] • 


Subnet: 10.30.0.0 ! 



ma Y Set Mismatch set to 
EMPTY 

r^TY Set C to 1 9 Connection h 
SPTip 



0 



First IP MpC added to 
output MPT 



FIG. 24c 




Object Type: MpQI] 


Subnet: 10.: 


10.0.0 



POINTS? 



R1.E0 

v 



Object Type: MpCT21 



SubnetmiO.0.0 



^Looping through steps 3, 4,!^ 
another IP MpC is added to 
V the MPT 



pomrnj 

POINTED 
R1.S0 



^ 

rzso: 
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Object Type: MpCffl 



Subnet: 10.30.0.0 



poinih? 



R1.ED 



\y 
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Q Still looping through steps 3, 
4, 5 the last IP MpC is added 
to the MPT , 



Object Type: MpC[2] 



Subnet10.10.0.0 



POOTER 



POWTER 



R2S0 



R1.S0 



rafirrm 

RZEO 



y 



\y 



\ Object Type: MpC131 
SubnetTdSo.0 



FIG.24e 



Object Type: MpCji] 



Subnet 10.300.0 



POINTER 



R1.B0 



V 



IP MPT, Got to last IP 
Connection 




Object Type: MpCP) 



Object Type: MpCg] 



Subnet! 0.1 0.0.0 



Subnet10.20;0.Q 



POINTER 



P01MTER RZSO 



R1.S0 



y 

\y 
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Object Type: MPT 



MpCs: 



Object Type; MpCf i] 
Subnet: 10.30.0.0 



Subnet: 9c 




FIG.24g 



Object Type: MPT 



MpCs: 
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Result is complete match 




/^/finding the first IPX Connection, an>t 
O a complete match on Subnet, the 
Urst IPX MpC is added to the MPT 



V 



Object Type: MpCffl 



flbjept Type: MpCf3I 



Object Type: MpCll] 



Subnet 10.30.0.0 



Subnet 9c 




Subnet10.10.0.0 



Subhet:10.20.0.0 



POINTER 



POINTER 



R2S0 



R1,S0 




^ CNOTIastlPXconnertion] 
(i?) C is set tola" 



©[R esult is complete match ] 
(Tjtne next IPX MpC is added to the? 




| Object Type: MpCt2] 

Subnet:10.10.0.0 



Subnet 7a 



POINTER 



POINTER 




POINTER 



RZEO 
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G ) Mo, C NOT last IPX connection 1 
(u j C is set to 98 



Object Type: MPT 



MpCs: 



Object Type: 



Q[ Result is complete match ] 




(TY the lastlPXMpC is added to the* 
MPT 



Object Type: MpC|21 



Object Type: MpC{31 



mm 



Subnet: 10.30,0.0 



Subnet 9c 



Subnet:10.10.0.0 



Subnet: 7a 

— rs 



R1,ED 

v 

FIG.24i 



Subnet:10.20.0.0 



Subnet 98 



POINTK 



POWTER 



R1.SO 



V 



RZSO 



POINlEt 



y 



R2.B) 



( The last IPX Connection has 
been added to the MPT, now 
EXIT the process 



\y 
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MpCs: 



FIG. 25 




Object TvoeMpE 



Object Type: MpC 



Subnet: 10.30.0.0 



Subnet 9c 



Subnet: 10.10.0.0 



Subnet 7a 




Object Type: RouterfSROi 
Hostname: R1 



Mega Type EmaaiEr 



NumbenO 



ARP 



Bandwidth: 10000 



Port 12] SO 



Delay: 100 



Port Addresses 



A 



Number: 0 



in'HDLC 



Bandwidth: 1544 



Delay: 2000 



Protocol: IP 



Aptt:ip3[L7^ffi5L255JDL0 

j~z — 



Port Ad dresses* 



Port_addr|21(Ri < saiPi) 



Protocol: IP 



Port_arJdr[1] blbdupxi) 



Protocol: IPX 



Adan9c 



AtkfcmiOAl 2S5L255L0J0 

2ZZ 



Portaddr{2] <ri^oipxi) 



Protocol: IPX 
AddnJa 



Type: MpC 



Subnet 10.20.0.0 



Subnet 98 




Or^rypgRouterfSRfj) 



PbrtadoVn] ffgso,iPxi) 



Port [1] SO 




Media Type Serial 


Port[2]E0 


NumbenO 


Media Type ethbmt 


EncapsJationrHDLc 


NumbenO 


Bandwidth: 1544 


Encapsulation: ARP 


Delay: 2000 


Bandwidth: 10000 


Port Addresses* I 


Delay: 100 


/ 




[Port Addresses* 


/ 




REHtadrJrflJ 




Protocol: IP 


PortadrJr[2| (rzeoipu 


AddniO.ld.4.2255.255fl0 


Protocol' IP 




AddnO.20S2255.255.0lO 



Protocol: IPX 



Addr:7a 



Port_addrI21 <rzeo,ipxi> 



J 



Protocol: IPX 
Addn98 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/10873- 



39/9B 





R1 




TO 


IP: i 


FIG. 26 




IPX 




IP: 10.10.10.2 255.255255J0 

IPX: 7a 



TO 


IPX: 7a 


R1 




T1 


IP: 10.10.103 255255255D 





IP Com 



Object Type: Corinfi] 



Subnet 10.10.10.0 



Pointers • 



POWTIR 



R1,TOJP1 



POINTER 



RZTOJPI 




POINTER 



•naTMPi 



IPX Conn 



Object Type: ConnQ] 



Subnet: 7a 



Pointers* 



poi 




R1.TWX1 



RZT0JPX1 



POINTER 



R3^0,IPX1 
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FIG. 27 




Set C to first MPC in MPT 




Does C have a 
non-IP Subnet 
and no IP 
Subnet?^ 



Inputs: MPT &SRO': 

Outputs: Updated MPT 
_&SR0's . 





Afts 




DoesC /"\ 


— Ho. 


have afl the pointers >y 


associated with ports that ^ 




haveanlP-uraiumbered / 




port address ? 






4- 


Add subnet T-umuntered" to the 
MPC in MPT referred to in C 
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Routed Network Using lp-unnumbered and also IPX interfaces 



FDDI 



Router 


so so 


Router 
(R5) 


8b 


f 0 ) 20.20.0.0 
Ft 


Router 

m 


so so 


Router 


9c 


(R6) 
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version 10.0 
I 

hostname R3 
j 

no veH routing 0000.0c08.S4dd 
S 

interface Loopback 1 

ip address 122.33.2.1 255.255.0.0 

interface SerialO 

ip-unnumbered loopback 1 CT) 
px network 8b 

interface Fdcfi 0 

address 20.20.1.1 255.255.0.0 
end 



Router R5: FIG.29C 



version 10.0 
hostname R5 

novel routing 0000.0d09.a5ee 

interface Loopback 1 

ip address 127.38.7.6 255.255.0.0 

interface SerialO 
DHJmurnbered loopback 1 
px network 8b 

end 
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Router R4: 



FIG.29H 



version 10.0 
! 

hostname R4 



novell routing 0000.0c04.3a3e 

! 

nterf ace Loopback 1 
ip address 127.38.7.6 255.255.0.0 
interface SerialO 
p-unnumbered loopback 1 
px network 9c 

interface FdrfiO 

ip address 20.20.0.0 255.255.0.0 
end 



Router R6: FIG.29d 



version 10.0 
{ 

hostname R6 
! 

novell routing 0000.0d05.4b4f 

! 

interface Loopback 1 

ip address 13Z43.12.11 255.255.0.0 

interface SerialO 
p-unnumbered loopback 1 
px network 9c 

end 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



Object Type: Router 



Hostname: R3 



Ports • 



Port [1]: LI 



Mafia Type: Loopback 



Number 1 



Encapsulation: none 



Bandwidth: 1 



:5 



Port Addresses 
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FIG. 30a 




Media Type: Serial 



Number 0 



Encapsulation: HDLC 



Bandwidth: 1544 



Delay: 2000 



Port addresses 



Port[3]:F1 



Media Type: FDOI 



Number: 1 



Encapsulation: FDDI 



Bandwidth: 100000 



Delay: 10 



Port addresses* 



Port 8ddr[1] (R3,F1,IP1) 



Protocol: FDD) 



Address: 20.20.0.0255.255.0.0 



Port_addr[1](R3,L1,IP1) 



Protocol: IP 



Address: 1223121 2551255100 



Port_addr[1l(R3,S0,IP1) 




Protocol: IP 



Address: • 



Static Routes: empty 



5 



Port_addr[2](^,SO,IPX1} 



Protocol: IPX 



Address: 86 



Object type Unnumbered 
Ret LI 
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Hostname R4 



Ports * 
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FIG. 30b 




Port[1]:L1 * 




Port[2]:$0 


Media Type: Loopback 




Media Type: Serial 


Number 1 




Number 0 


Encapsulation: none 




Encapsulation: HDLC 


Bandwidth: 1 




Bandwidth: 1544 


Delay: 5 




Delay: 2000 


Port Addresses* 




Port addresses *n. 



Encapsulation: FDDI 



Bandwidth: 100000 



Port addresses < 



Port_addr[1] {R4,F1,IP1) 



Protocol: FDDI 



Address: 202000255.255.00 



Port_addr[1](R4X1,IP1) 


Port_addr[lj (rHS0,IP1) 




Protocol: IP 


Protocol: IP 


Port_addr[1] (R4,S0,IPX1) 


Address: 12435.4J 255l255H0 


Address:* 


Pratocok IPX 


\ 


Address: 9c 



| Static Routes: empty 



Olq*ectType:Uiinurnoered 
Ref: LI 
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Object Type: Router 



Hostname R5 



Ports* 
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FIG. 30c 




POrt [11: LI 



Number: 1 



Encapsulation: none 



Bandwidth:! 



Delay: 5 



Port Addresses* 



Port [2]: SO 



Media Type: Serial 



Number 0 



Encapsulation: HOLC 



Bandwidth: 1544 



Delay: 2000 



Port addresses ' 



Port_addr[1](R5,L1JP1) 



Protocol: IP 



Address: 126^5255255.0.0 




Port_addr[1] (R5,S0JP1) 



Protocol: IP 



Address: • 



Object type: Unrumbered 



Port_ad*[1) (R5,S0,IPX1) 



Protocol: IPX 



Address: 8b 



RehL1 



Static Routes: empty 
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Object Type: SPT 



Protocol: IP 



Conns* 



Object Type: Conn|1] 



Subnet 20.20.0.0 



Poofters* 



FIG. 30e 





POINTER 




IRF1JP1 


POUTER 




R3.F1JP1 



Object Type: SPT 



Protocol: IPX 
Conns* 



Object Type: Conn[1] 



Subnet 8b 



Pointers* 





POINTER 




R53UPX1 


POINTER 




ROSOPX1 





Object Type: Conn[2] 



Subnet 9c 



Pointers* 
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MPT 



Object Type: MPT 



MpCs: 



0 



FIG.30f 




| Object Type: MpC [2] 



Object Type: MpC [31 



Object Type: MpC [11 



Subnet IP-unnumbered 



Subnet: IP-unnumbererd 



Subnet: 9c 




Subnet 20.20.0.0 
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START 



FIG. 31 




Initialize the output SPTp to empty 




Initialize PA to the first Port 
Address of Protocol P in the list 
of routers 



Each Distinct (subjnet is 
added to the SPT as a 



connection" 



No 




AddSubnetp{PA)to5P7> 




No 



a 





Add pointer to PA under the 
connection in SPT matching 
subnetp(PA) 




ForaflSRQ'sin 
the list of routers 
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FIG: 32 



Note: ^\ 
Original SPTBuld Flow 



Mutepont WAN extensors 




AddSubnetp{PA)to5P7> 



£1 



AsociatedwithPA 
Encapsulated 



Set FRM to the set of frame-relay 
maps associated vvitli PA's Port 



Add pointer to PA under 
the coraiection in SPT 
matching subnetp(PA) 



SetFrm_mernberto 
next dement of FRM 



Set Frm_member to the first 
element of FRM 



ConnSet = Conns matching Subnet(PA) in SPTp 
with a pointer exactly matching Frm member 




Addsubnet(PA}toSPTpanrJ 9 ) 
under it a pointer to PA 



toSPTp& 
under His, Poiiters to both PA 

and to Port Address 
corresponrjngtoFrm member 



Is there a 
'menterofCornSeT 
having just one 

V 
Yes 



AddpontertoPAtDthis 
nBTte havig just ore poirrter 




ForalSRO'sm 
.the list of routers 
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start" 




Initialize the output SPTp to empty 



Initialize PA to the first Port Address 
of Protocol P 



f Note: *" 
Original SPTBuBd Flow 



Mutepoht WAN extensions 




FIG. 33 



AddSutmsWPAItoOT"? 



Associated with PA Frame 
Relay Encapsulated 



Set FRM to the set of frame-relay 
maps associate^ with PA's Port 



SetFrm_memberto 
next element of FRM 



Set Frmjnernber to the first 
element of FRM 

i — 



SI 



Add pointer to PA 
under the connection 
in SPT matching 
subnetp(PA) 



No 



QConnSet ■= Conns matching Subnet(PA) 
in SPTp with a pointer exactly matching 
Frm member 





33, 



C 



33. „ 
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Addsubnet(PA)toSPTpai 
under it a pointer to PA 



AddsuhnetKPA)toSPTp& 
under this, Pointers to both PA 

and to Port Address 
corresponding to Frm member 




Add pointer to PA to this 
member having just one 
pointer 



SI 



Set PA -next Port 
Address of type? 




For afl SRO's in 
the ist of routers 
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FIG. 34 
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ObjectType:SPT 



Protocol: IP 



Conns 



Object Type: Connf 1) 



Subnet 117.33.4.0 



Pointers: 




POINTER 



RISOJP 



POINTER 



R2S0JP 



POINTER 



Raso,ip 



POINTER 



R4,S0,IP 




FIG. 35 



SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



55/98 



PCT/US96/10873 



Object Type: SPT 



Protocol: IP 



Corns 



FIG. 36 



Object Type Conn[1] 



Subnet 117.33.4.0 



Pointers: 




R1^0,IP 



Object Type: Conn[2] 




R4,saiP 



Subnet 117.33.4.0 



Pointers: 



R1.S0,IP 



POINTER 



RZSO.P 



Object Type: Corm[3] 



Subnet: 11 7.33.4.0 



Pointers: 



POINTER 



R1.S0.IP 



POINTIR 



Rasaip 




Object Type Conn[4] 



Subnet: 117.33.4.0 



Pointers: 




POINTER 
RiSaiP 



POINTER 
R3.S0.IP 




SUBSTITUTE SHEET (RULE 26) 



WO 97/49214 



PCT/US96/1087> 





Object Type: Router 
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Hostname: R1 


FIG. 37 


Ports* 



Port [1]: SO 



Media Type: Serial 



Number 0 



Encap: Frame Relay 



Bandwidth: 1544 



Delay: default 



Port Addresses: 



Port_addr[1](R1,S0,IP1) 



Protocol: IP 



Address: 117.33.4.1 255.255.0.0 




Broadcast: yes 

5J 
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FIG. 38b 



version 10.0 
! 

hostname R1 
! 

ip subnet-zero 
j 

Interface SerialO 

description Serial 0 

encapsulation Frame-Relay 

ip address 117.33.4.1 255255.0.0 (jj 

frame relay map ip 1 1 7.33.4.2 100 broadcast 

frame relay map ip 117.33.4.3 101 broadcast 

frame relay map ip 1 1 7.33.4.4 1 02 broadcast 

G) 

router np 109 v_y 

network 117.33.0.0 

end 



FIG. 38c 



version 10.0 
j 

hostname R3 
i 

ip subnet-zero 
i 

interface SerialO 

description Serial 0 

encapsulation Frame-Relay 

ip address 1 17.33.4.1 255.255.0.0 

frame relay map ip 1 17.33.4.1 100 broadcast 

frame relay map ip 1 1 7.33.4.2 101 broadcast 
j 

router rip 109 
network 11 7.33.0.0 
end 



version 10.0 
j 

hostname R2 
! 

ip subnet-zero 

! 

interface SerialO 

description SerialO 

encapsulation Frame-Relay 

ip address 1 17.33.4.1 255.255.0.0 

frame relay map ip 1 1 7.33.4.1 100 broadcast 

frame relay map ip 1 1 7.33.4.3 101 broadcast 

router rip 109 
network 117.33.0.0 
end 



FIG. 38d 



version 10.0 
! 

hostname R4 
! 

ip subnet-zero 
j 

interface SerialO 

description Serial 0 

encapsulation Frame-Relay 

ip address 1 17.33.4.1 255.255.0.0 

frame relay map ip 1 1 7.33.4.1 100 broadcast 
! 

router rip 109 
network 117.33.0.0 
end 
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Object Type: SPT 



Protocol: IP 



Conns: [Empty] 




Initialized SPT set to 



EMPTY 



PA - 117.33.4.1 255.255.255.0 



© 

(T) [ No-SubnetKPAWrinSPTp 



© 



Object Type: SPT 



Protocol: IP 



Conns: 



Object Type: Connflj 



Subnet 117.33.4.0 



Pointers: 



© 



POINTER 



R1.S0JM 



(nT) fNO- PA not test Port Address 



© 



PA - 117.33.4.2255.255.255.0 



(P) ^YES: 117.33.4.1 belongs to subnet 117.33.4.0 
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© 

o 

© 

© 

© 
© 



© 



YES - Port is Frame Relay Encapsulated 



FRM -{117.33.4.1; 117.33.4.3} 



Frm member - 117.33.4.1 



ConnSet - {Conn[1]} 



NO: ConnSet not EMPTY 



Object Type: SPT 



Protocol: IP 



Conns: 



Object Type: Connl 11 



Subnet: 11 7.33.4.0 



Pointers: 



POINTER 




L PONTER j 
! RZS0.IP1 



© 



NO: FRM member not last member of FRM 



PCT/US96/10873^ 



YES: a member of ConnSet bas only 1 pointer 
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© 
© 
© 



© 
© 

© 



Frmjnernber = 117.33.4.3 



ConnSet = EMPTY (no Conn[3] exists yet) 



YE&ComSet EMPTY 



NO: no Com matching. 



Object Type: SFT 




Subnet: 117.33.4.0 



Pointers: 



Object Type: Conn[2] 



Subnet 117.33.4.0 




YES: Frm_member is last member of FRM 



|N0 • PA is/atf last Port Address 



PA = 117.33.4.3255.255255.0 
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YES • [1 17.33.4.0 255.255.255.0] 



YES • The Port is Frame Relay Encapsulated 



FRM = {117.33.4.1; 117.33.4.2} 



Frm_member- 117.33.4.1 (R1,S0,IP1) 



ConnSet - {Conn[1]} 



NO: ConnSet not EMPTY 



NO: no mbr of ConnSet has only 1 pointer 



Object Type: SPT 



Protocol: IP 



Conns: 



Object Type: ConnH] 



Subnet 117.33.4.0 



Pointers: 




Object Type: Conn|2| 



Subnet 117.33.4.0 



Pointers: 



PONTHl 



Ri^aipi 



R2S0F1 



z 



POINTS* 



rzso.pi 
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Object Type: Connfll 



Subnet: 11 7.33.4.0 



Pointers: 



POINTER 




\ITER 



R1S0JP1 
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irWg^nptiast member of FRM 



(57) ( Frmjnember = 1 17.33.4.2 (R2,SpjplT 



NO: ConnSet not EMPTY 



(T) (ConnSet » {Conn[21) 1 

© 

0 
© 



YESGomH 



Object Type: SPT 



Protocol: IP 



Object Type: ConnUI 



Subnet 117.33.4.0 




Pointers: 



POINTER 




Object Type: Conn[2] 



Subnet 117.33.4.0 



Pointers: 



R1,S0,IP1 



POINTER 


POINTER 


RZSO.IP1 


R2S0,P1 



Object Type: Connf3] 



Subnet: 11 7.33.4.0 



Pointers: 



^POJNtER_ 




YES -last member of FRM 



© , 

(J) (NO - PA is /wrlast port address of type? 
(n) [PA " 117.33.4.4255.255.255.0 1 



POINTER 




POINTER 


R1.S0.iPl 




Raso.pi 
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3 



(?) I YES -[1 17.33.4.0 inW 



(?) [ YES • itg Frame Relay Encapsulated ] 
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FRM - {117.33.4.1) 



Frm member- 117.33.4.1 J 



FIG. 39 f 




CotroSet- (Conn[1]; Coring]} 



NO: CoimSet not EMPTY 



] 



NO: no ConnSet members have only one pointer 



© 



Object Type: SPT 



Protocol: IP 



Conns: 



Object Type: Conn[1] 



Subnet 1173140 




Pointers: 



Object Type Conn[2] 



Subnet: 117.33.4.0 



Pointers: 



pouirrm 



R1,S0UP1 



pointer 



RZSOJP1 




Object Type: Conn[3] 



Subnet 11733.4.0 



Pointers: 



Object Type: Conn[4] 



Subnet: 11733.4.0 



Pointers: 



POINTER 



rzsojpi 



POINTER 



R3,S0,P1 



/ \ 




POINTER 



R1.SQJP1 



POINTER 



R3£0,IP1 



LPOWTER 
iRI^OIPI 



' L POINTER , 

Ir4,sojpi 



(V) [ YES- FRM g Last Element 



(V) (YES -PA is last Port Address ■» ( gn?D 
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Set Violations to EMPTY 



FIG. 40 



Set C = first com in SPTip 




■0 



Pointers refer to Port 
Addresses, this function 
analyzes bandvudth/delay 
values associated with th 
Port Addresses 







Yes 


Add Ports in C with 

conflicting / 
bandwidth/delay 
to violations 





0 



NOTE: > 
Input SPTip&SRO's 

Output: Violation Set 
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START 



FIG. 41 




Set Violation List to EMPTY 



I 



^1 Set ST to the first static route (in the 
(2^ set of routers) 



Set ST to Next Static Route 




— : 1 




No j. 



NOTE: 
Input SPTr&SRO's 



ion Set 






No G) 




Add ST(amotated with the 
Router it is contained hi) to the 
Violation List 
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Inputs: SPTp and the SRQ's 
it points to, and operational 
status for each router, router 

port and connection 
Outputs: routing tables for 
Protocol' for each router 
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For each router (In the set of SRO's) initialize its routing table 
(for Protocol] 3 ) to EMPTY kJ 



For each router that has operational status, put in a routing 
table element for each of its Port Addresses (for Protocol P) 
and static routes associated with Ports in operational status 



— : i + - 

For each operational router, Ro, for each of Ro's Ports Po, that is operational and for each of Ro's 
routing protocols (for P) an ujjdate rress^ 
if it is not empty; the update message wiB consist of {rt d | rt_el = SEND{rt_dJn_tab!e, 
RP, < Ro,Po > where rt el in table is a routing table element in Ro's routinpTtabie) 



0 



For each connection (in SPTp) that receives an update message from Router Ro, Port Po, 
if it is operational then the update wffl be passed to ay the router ports it is pointing to' J) 
except for Ro,Po: if the connection is not operational afl update messages are dropped 



For each operational router Ro and each update UPD that it receives through Port Po, if 
Po is operational, the set UPD TG PROC will be formed; if Po is not operational, UPD 
is dropped; UPD_TO_PROC is defined as the set: {rtel | rt_el = 

RECEIVE(rt_el_upd,RP, < Ro,Po > ) where rt_el_upd is a member of UPD, and rt el's 
destination is not in Ro's routing table, or if it is then it either has a better cost/admin 

distance or an equal cost/admin distance, but not an exact match) 



For each UPD_TO_PROC that router Ro forms, add each of its members to Ro's routing 

table, removing any elements already in table with matching destinations, but higher \t) 
trat/adnin distance 



For each UPD TO PROC set remove any element if it had matched me destination and 
cost/admin oTstance of an etement already inthe table 



0 



For each UPD_To_PRDC set formed by router Ro, for each routing protocol rp_x that 
Ro is running, and each operational Port Po, send out the following update set to the 
connection that points to Ro,Po: {rt_el_out | rt d out = SEND(rt_el_upoV 
rp_x, < Ro,Po > where rt el upd belongs to UPD TO PROC ) 
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Object Type: Routing Table 



Protocol: IP 



Gateway of Last Resort: 



Elements • 



FIG. 45 



Routing Table Element EL[1] 



Destination: 



Cost Paths* 



Protocol: 



Cost/AdminDistance: 



Interface: 



Next hop pointer 



Interface Conn: 




Routing Table Element EL[2] 



Destination: 



Cost Paths* 



Protocol: 



Cost/AdminDistance: 



Interface: 



Next hop pointer 



Interface Conn: 



Routing Table Element EL[N] 



Destination: 



Cost Paths • 



• •• 



Protocol: 



Cost/AdminDistance: 



Interface: 



Next hop pointer: 



Interface Conn: 



Protocol: 



Cost/AdminDistance: 



Interface: 



Next hop pointer 



Interface Conn: 
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ED 



R1 



so 



70/98 



Conn [2] 



Conn[4J 



so 



R3 



ED 



EO 



R2 



so 



Com [3] 



so 



R4 



FIG. 47 









R5 




DA3 

(DEST 
ADDRESS) 











Data Labels Used in CPS 
Discussion 

SC Source Connection 
DC Destination Connection 
SA Source Address 
M Destination Address 
CPS Completed Path Set 
APS Active Path Set 
SPT Single Protocol Topology 
H Current Router 
NC Mew Connection 
EL Routing Table Element 

Protocol 
CPO Cost Path Object 



Definition: Completed Path Set - CPS 



The Set hawng: no elements; 1 element; or, 
morethanl element 

to dements means: No path from SA to DA 
One (1) element means: One path from SA to DA 
Morethanoneelement: Multiple paths from SA to DA 

The CPS for SA to DA2 looks like: 

{[SA;ConnI1];Rl;Conn[2I;R3;Conn[4];DA2] 
[SA;Corm[1];R2;Conn[3tR4;Conn[4]DA2j} 



Hie CPS for SA to DAi looks like: 
{[SA;ConnntQAi]} 

The CPS for SA to DA3 looks Ike 
{} 
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START 




Initialize the set of Completed Paths (CPS) to EMPTY 



FIG. 48a 



0 



Initialize RLPS to EMPTY 



0 



Note: No Paths 
Found 




No 




/Mote: SA and DA on same subnet 
thus there is one path, which is 
from SA through Subnet/Conn 
SCtoDA 



Initialize SC to the connection in SPTp 
matching SA's subnet 



3 



Initialize DC to the connection in SPTp 
matching DA's subnet 



0 



SetCPS = {[SA;SC;DA]} 



Yes 



(V) 
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FIG. 48b 



Initialize the Active Path Set (APSJ to 
"}fSA^e;IRm...ISA;Sa-[RW]} 
for each router ft mttexed by a pointer in SC 




3 



Set Current Path (CP) to a ^ 
path in APS & (gj 
&LiES^ ^ 



Set Current Router (GR) to the last 
router in the path CP 



Yes 




/fi>r Example: 
In the CPS: 1 
[SA;SC;R1;CormZ-R5] 
the Current Router (CR) 
isset toR5. 



Reft FIG. 59 



Set Cost Path Objects(CPO's) to the set of 
connections/next router pairs associated 
with rouong table elements that match OA 
in CFLRoutingTablep 



0 
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FIG. 48c 



48. B 



( Note: There was no route 
in CR that matches OA. 
Goto (8) figure 48b 




Set EL to a member of CPO 



Set EL aside/ empty CPO 



Add [CP; 
ELConn;DA]to 
CPS 



f Note: EL is a route pointing to 
an interface on a subnet that D 
is directly connected to 



0 
0 
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Inputs - RT- Routir^bie &" DA - Destination Addrres 

Outputs: CPO - set of Cost Path Objects on matching element (empty if 



no-match) 




Set EL to element in RT belonging 
to DA's major net and having the 
most specific mask 
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Object Type: SPT 



Protocol: IP 



Conns 



Object Type: ConnfU 



Subnet: 10.10.0.0 



FIG. 52 



Pointers: 



POINTER 



fi1.E0,IP 



POUTER 



RZEftlP 





POWER 



Object Type Conn[4J 



Subnet: 20.20.0,0 



Pointas: 



PQWTER 


POINTER 


R31E0JP 


R4,EQ,(P 



Object Type Connf3] 



Subnet: 199.28.78.0 



Pointers: 



POWTER 



Rasojp 



POINTER 



R4.S0.P 




Object Type Corm[5] 



Subnet: 199.28.77.0 



Pointers: 



POINTER 



Ri^aip 



POINTER 



R4S1JP1 
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Ibject Type: Routing Table 



Protocol: IP 



Gateway of Last Resort Empty 




Protocol: Direct Connect 



Cost/AdminDistance: [0/0] 



Interface: EO 



Next hop pointer 



Interface Com: Conn 11] 




Routing Tal 


te Element EL[2] 


DestHiatio 


1:199.28.77.0 255.255.255.0 


Cost Path: 


• 



Routing Table Element EL[3] 



Destination: 199.28.80.0 255.255.255.0 



Cost Paths* 



Protocol: Direct RIP 



Cost/AdminDistance: [1/120] 
Interface: S1 



Next hop pointer: 



Interface Conn: Conn [5] 



Protocol: Direct Connect 



Cost/AdminDistance: [0/0] 



Interface SO 



Next hop pointer: 



Interface Conn: Conn [2] 



Routing Table Element EL[4] 



Destination: 20.20.0.0 255255.0.0 
Cost Paths • 




Protocol: RIP 



Cost/AdminDistance: [1/120] 



Interface: SO 



Next hop pointer. 



Interface Conn: Conn [2] 



Protocol: RIP 



Cost/AdminDistance: H/1201 



Interface: S1 



Next hop pointer 



Interface Com: Conn [51 
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toject Type: Routing Table 



Protocot IP 



Gateway of Last Resort Empty 



Routing Table Element ELflJ 



Destination: 20.20.0.0 255.255.0.0 



Cost Paths- 



FIG. 54 



Protocol: RIP 



Cost/AoninDistgnce: 11/1201 



touting Table Element EL[2J 



Interface SO 



Next hop point Rn fR4.E0.IP11 



Interface Conn:nnnnCT 



Destination: 199.28.77.0 255.255.255.0 
Cost Paths • 



Routing Table Element EL[4] 



Destination: 199.28.80.0 255.255.255.0 



Cost Paths 



Protocol: RIP 



Protocol: Direct Connect 



Cost/AdrraiDistance: fD/OI 



Interface: EO 



Next hop pointer: [R1,E0,IP1] 
Interface Conn :Conn 111 



Cost/AominDistancE- [1/1 201 



Interface: EO 



hop pointer: [R2,E0,IP11 



Interface Conn .-Conn Ml 



Routing Table Element EL|3J 



Destination: 10.10,0,0 255.0.0.0 



Cost Paths 



Protocol' Direct Comect 



Cpst/Adrrwtfctance: fO/Dl 



Interface: EO 



Next hop pointer: 



interface Conn : Conn 111 
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Object Type: Routing Table 



Protocol: IP 



Gateway of Last Resort: Empty 



Elements • 



• •• 



Routing Table Element ELM 




Destination: 10.10.0.0 255.255.0.0 


Cost Paths* 








Protocol: RIP 




Cost/AtfrnrnDistance: 10/11 


Routing Table Element EL[2] 


Interface: SO 


Destination: 19028.78.0 255255.255J) 


Next hop pointer: mwi] 


Interface Conn: Conn [2] 


Cost Paths* 



FIG. 55 



Protocol: Direct Connect 



Cost/AdminDistance: [0/0] 



Interface: E0 



Next hop porter ursojpi] 



Interface Conn: Conn [4] 




Routing Table Element EL[3] 


Destination: 20.20.0.0 255.0.0.0 


Cost Paths 


• 










Protocol: Direct Connect 




Cost/AdmmDistartce:[0/0] 




Interface: E0 




Next hop pointer: 




Interface Conn: Com [4] 
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Object Type: Routing Table 



Protocol: IP 



Gateway of Last Resort: Empty 



FIG. 55a 




Protocol: RIP 



Cost/AdriinEfetancftn/m 



Interface SI 



Next hop pointer: imsijph 



Interface farm:Cohnf5I 



Routing Table Element EL[3] 



Destination: 2021011 mz&nn 



Cost Paths 



Protocol: Direct Connect 



Cost/AdminDistanc9:fQ/ni 



Interface E0 



Next hop pointer: 



Interface Conn: Conn 141 
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FIG. 56a 



f Note: The following sequence of data element values (from those fisted in Figure 3- 1 ) and ^ 
topology diagrams shows, step-by-step, how the Current Path Set is built from Source Address 
(SA) to Destination Address (DA). In the diagrams, circled f~\ numbers refer to locations in 
ig. 48 as similarly labeled vHV 



Beginning at START, the process moves as shown up to the first decision block: 
Q CPS- { } (Empty) Q Yes Q SC-Conn[1] 

Q DC - Com[4] 0 No, SC not equal DC 



As of step (^) . the values of the Active Path Set are: 



APS = {|SA;Connl1tR1l ISA;ConnI1fcR2l} 



Corm[1] 



io.mi.7 



SA.. 

(SOURCE 
ADDRESS)! 



.EO. 



1D.1O0D 1.1 
255255J10 



ED 



R1 



so 



Conn [2] 



Conn [4] 



so 



.1 19028.77.0 2 

"S^ 255255255.0 
SI 



R3 



EO 



10.1tLDH 12 
2S255DD 



R2 




2020.1.1 
255255.0.0 



so Conn 13] 



.1 19928.78.1 
255255255.0 



SO 



R4 



EO 



2020.12 
25525500 



" Dotted bies indicate the progress of the APS bidding sequence 



- 2020.1.9 



DA 

(DESTINATION 
ADDRESS) 
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FIG. 56b ... Flowchart Steps (b^) Through- (n) 



© Current Path - 'A' (n) 

Current Router = R1 




Marlines indicate the ptqpSS^Re active path buldtng sequence 



OT: Routino Table /?Rlf\ 



Protocol: IP 



6twy Last Resort: Em pt y 



Etements.... 



RtgTM Element EL[1] 



Destiriation:io.ioiio255255jj 



Cost Paths • 



RtgTblElementjl[2] \ 



PrOtOCOl: DirBrtHnnnort 



_Cost/AdminDistanro[ n/n| 



Interface: Efl 



Next ho p pnbtw 



Interface Cnmrnnnnfrj 



Destination: 19928.77^25^9" 



Cost Paths • 



Protocol: Direct Connect 



Cost/AdmrnDistanrP- fn/n] 



Interface SO 



Next hoo p nintPr: 



Interface Corm^CtmrrfZf 



• •• 



RtgTbl Element: E1J41 



Destinatpir aao^gMEoo 



Cost Paths 



' At Step 12, Cost PaiN 
Objects are set to the 
Connections/Next Router Pairs 
found in the Routing Table 
Elements associated with the 
v Destination Address 



^t/AdminDistance:f1/1?ni 



Protocol: RIP 



Interface: SO 



Next hop pointer rasgipii 



rnterface Com: Conn f2I 
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Protocol: RIP 



Cost/AdrninDistance: M/1?fy 



Interface: S1 



Next hop pointer: mstpii / 



Interface Conn:Cnnnf5lX 
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FIG. 56C ■ FtowwchartStEps(T)Through(^?) 

1*Pass W W 



Finding routes to DA, test 13 is failed 




EL is set to a member of the Cost 
Path Objects (CPO's) 



Dest. Conn (DC) - Conr44] 
(ie)| ELConn-ConnI2]: 
Faistest 



Protocol: RIP 



Cost/AdmnDistance: [1/1201 



Interface: SO 



►Next hop pointer [R3,S0JP1] 



Interface Conn: Conn 121 



Add [CP;EL.Conn; EUNextRouter to APS 

APS - {[SA;Cpnn[lJ;R1;Conn[2];R3L [SA;Connfll;R2]} 

\ A ; =b • 



10.10.1.7 



SA 

(SOURCE 
ADDRESS) 



Conn [ll 



.m 



10.1OO0 1.1 
255255jO0 



• B 



BO 



IOIOOjO 12 
2S255J3JD 



Conn [2].,- 



Conn [4] 



RT 



so.. 



so 



19028.77.0 
25525 5255D 



R2 




*R3 



33 



Si 

19928.781) 



20201.1 
255255JO0 



so Conn [31 



1 189L2a78.1 
255255255J} 



R4 



GO 



202012 

ZS.2550JD 



"* Dotted Ones indicate the progress of the APS building sequence 



- 2020.1.9 



DA 

(DESTINATION 
ADDRESS) 



After Step 1 7, the flow branches back 
up to Step 13... 
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FIG.5Bd ' flowchart Steps (^Through 

2nd Pass W W 



routes to DA,test 13isfailedj 

/^ELissettoamemberotheCos?\ 
Path Objects (CPO's) 




CPO Set to EMPTY 



Protocol: RIP 



Cost/AdrninDistancg [1/1 201 



Interface: SI 



'Next hop pointer: [R4,S1.IP11 



Dest. Conn (DC) = Conn[4I 

ELXoim- Conn [5]: 
Fajstest 



Interface Conn : Crow [R| 



©Add ICftELConn; EL.AJextRouter to APS 
{ISAjComIIW fSA;CQnn[1i;R2]} 




r 



After Step 1 7, the flow branches back 
MPtoStep 13... 
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FIG. 56e Flowchart Steps Cu) Through (is) 

3rd Pass 



CPO is EMPTY, Go To Step 8 



or 



APS is Not Empty 




CR-R4 



CP .- [SA;Conn[1];R1;Coi 



& 



At Step 12, Cost Path Objects are set to the Connections/Next Router Pairs found in the" 
Routing Table Elements associated with the Destination Address 




/EL is set to a member of the\ 
Cost Path Objects (CPO's) 



CPO Set to Empty 



Protocol: Direct Connect 



Cost/AdminDistance: [0/01 
Interface: EO 



Next hop pointer: 



Interface Conn: Conn 141 



CR = 
Router R4 



si 



DesLConn(DC)- Conn[4] 
ELConn = Conn [4]: 
YES Condition 



0T *" 



!SA;ConnI1l;R1;Conn[5];R4;Corin[4tDA] 
to CPS (where CP -[SA;Conn[1l;R1;Conrr[5l;R4D 
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FIG. 561 ■ Flowchart Step® 
yPass 



APS = {ISA;Conn[1];R!;Conn^ 



Connfl] 



iaiai.7 




Com [2] 



Conn J4] 







A.. 18a2&770 2 
*sJ • ... Wttc-xxn 


si 




i9a28.78^Stonn.[5] 






so 


Conn [3] 2 2 


.1 


19328,78.1 go 
25E255255D 



R3 



BO 



ZL20.1.1 
255255.0.0 




2020.1.2 
255255D.0 



- 2020.1.9 



' DA 

(DESTINATION 
ADDRESS) 



N0TE: At this juncture, the first Completed Path from SA to DA has been estabfehed; 

^^uf ^^^ ^e botweenStep 13, and Step 8 untiaO paths have 
been established. ThentheAPSwi beernpty M 

and the algorithm exited. 
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Object Type: Access List 



Number 



Elements 



FIG. 57 



Element [1] 




Action: 


Address: 


Mask: 


Element [N] 




Action: 


Address: 


Mask: 
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" Address (addr being checked) & 
AccL (access list being matched 
against) 



START 




Set EL to first element of AccL 
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FIG. 59 



Starting after (Yf) 
in Figure 48b 



Set InPort to the Port on CR 
pointed to by the connection in 
CPpreceetfingCR 



0 
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fie This chart integrates with 
Fig. 48b 



FIG. 61 

Starting after C\ti) " 
in Figure 481^ 
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FIG. 62 




Initialize the CPS to EMPTY ~Y7\ 



Initialize the RLPS to EMPTY 




initialize DC to the connection in SPTp 
matching DA's subnet 






SetAP 


Sto{[R]} \ 



3 
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FIG. 68a 



Router R1: 



version 10.0 

! 

hostname Routerl 



source-braigerinjgraup7 

sourretolge 7 tcp 30.50.21 

! 

interface Loopback 1 

ip address 50.7.8.3 255.255.0.0 
j 

end 



FIG. 68b 



Router R6: 



version 10.0 
j 

hostname RouterS 
I 



sourceiridge 7 tcp 50.7.8.3 



ip address 30.50.Z1 255.255.0.0 
! 

end 
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ROUTER RUStdSRO]" 



SRB Bridge Groups* 



ROUTER R6,[StdSR0J 



SRB Bridge Groups < 



pRBBridgaGroupfl] 




Group Number 7 




Peers* 

- v 












RSRB Peerfl] 






Encapsulation Type: TCP 






Address: 30.50.Z1 





SRB_Bridge_Group[1] 



Group Number 7 



Peers 



RSRB_Peer[1] 



Encapsulation Type: TCP 



Address: 50.7.8.3 
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FIG. 70 




START 



Initialize Conflicts to EMPTY 



Set R to the next router in the fist 
ofSRO's 



Set R to the first router in the list 
ofSRO's 



0 




Set P to the first RSRB or DLSw 
remote peer inR 



Set P to the next RSRB or DLSw 
rem otepeerinR 

(») No 



tsP the last RSRB 
or DLSw remote 
Yes ^s^peerinR 




Output:: Conflict List 
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-FIG. 7-1- 

/ NOTE N 
Input: List of SRO's 
Output:: Conflict list 
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SI 



Set R to the next router in the list of 
SRO's 



Initialize Conflicts to EMPTY Jf T) 



Set R to the first router in the list of 

SRO' s ^) 




Set N to the next neighbor 
statement in the BGP object for R 




Set N to the first neighbor statement n the 
_ BGP object for R 
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FIG. 73 



Set RoutingLoops to EMPTY f p 



Set R to the first router h the list (_ 
ofSRO's JJ) 








set C to the first connection in SPTp not | 
directly attached tnR r 


Set C to the next connection in 
SPTp not directly attached to R 






No^X 






Yes 



No 



Does<C,R> 

"match" any element in 
Routing_Loops 

? 

No 

DoesCPS^ 
"with source R and destination* 
connection C produce a iion-empty 
RoutingLoops Set (RLPS) 

Yes" 



For each path Pin RLPS, put i^n 
<C,P> in Routing Loops Kiv 
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